whether a particular function is implemented at application or
our runtime interpreter is " restricted python"
+ur runtime interpreter is "ython"
In order to make a C code generator feasible all code on interpreter level has
enables the code generator to emit efficient machine level replacements
for pure integer objects, for instance.
-Pylint_ is a static code checker for Python. Recent versions
-(>=0.13.0) can be run with the ``--rpython-mode`` command line option. This option
-enables the RPython checker which will checks for some of the
-restrictions RPython adds on standard Python code (and uses a
-more aggressive type inference than the one used by default by
-pylint). The full list of checks is available in the documentation of
-RPylint can be a nice tool to get some information about how much work
-will be needed to convert a piece of Python code to RPython, or to get
-started with RPython. While this tool will not guarantee that the
-code it checks will be translate successfully, it offers a few nice
-advantages over running a translation:
-* it is faster and therefore provides feedback faster than ``translate.py``
-* it does not stop at the first problem it finds, so you can get more
- feedback on the code in one run
-* the messages tend to be a bit less cryptic
-* you can easily run it from emacs, vi, eclipse or visual studio.
-Note: if pylint is not prepackaged for your OS/distribution, or if
-only an older version is available, you will need to install from
-source. In that case, there are a couple of dependencies,
-logilab-common_ and astng_ that you will need to install too before
-.. _Pylint: http://www.logilab.org/project/pylint
-.. _logilab-common: http://www.logilab.org/project/logilab-common
-.. _astng: http://www.logilab.org/project/logilab-astng
- faking <type 'posix.stat_result'>
- faking <type 'posix.statvfs_result'>
Module directories / Import order
contains pure Python reimplementation of modules.
The files and tests that we have modified from the CPython library.
The unmodified CPython library. **Never ever check anything in there**.
by default and CPython has a number of places where it relies
on some classes being old-style.
-If you want to change a module or test contained in ``lib-python/2.5.2``
-then make sure that you copy the file to our ``lib-python/modified-2.5.2``
+If you want to change a module or test contained in ``lib-python/2.7``
+then make sure that you copy the file to our ``lib-python/modified-2.7``
directory first. In mercurial commandline terms this reads::
- hg cp lib-python/2.
5.2/somemodule.py lib-python/modified-2. 5.2/
+ hg cp lib-python/2./somemodule.py lib-python/modified-2./
and subsequently you edit and commit
5.2/somemodule.py``. This copying operation is
+``lib-python/modified-2./somemodule.py``. This copying operation is
important because it keeps the original CPython tree clean and makes it
obvious what we had to change.
use your codespeak login or register
-If you already committed to the PyPy source code, chances
-are that you can simply use your codespeak login that
-you use for subversion or for shell access.
-If you are not a commiter then you can still `register with
-modifying Issues from hg commit messages
-XXX: to be written after migrating the issue tracker away from codespeak.net
+If you have an existing codespeak account, you can use it to login within the
+tracker. Else, you can `register with the tracker`_ easily.
.. _`register with the tracker`: https://codespeak.net/issue/pypy-dev/user?@template=register
-Our tests are based on the
new `py.test`_ tool which lets you write
+Our tests are based on the `py.test`_ tool which lets you write
unittests without boilerplate. All tests of modules
in a directory usually reside in a subdirectory **test**. There are
basically two types of unit tests:
- **Application Level tests**. They run at application level which means
that they look like straight python code but they are interpreted by PyPy.
-Both types of tests need an `objectspace`_ they can run with (the interpreter
-dispatches operations on objects to an objectspace). If you run a test you
-can usually give the '-o' switch to select an object space. E.g. '-o thunk'
-will select the thunk object space. The default is the `Standard Object Space`_
-which aims to implement unmodified Python semantics.
.. _`standard object space`: objspace.html#standard-object-space
.. _`objectspace`: objspace.html
.. _`py.test`: http://pytest.org/
python test_all.py file_or_directory
which is a synonym for the general `py.test`_ utility
-located in the ``py
py`` directory. For switches to
+located in the ``py`` directory. For switches to
modify test execution pass the ``-h`` option.
which contain unittests. Such scripts can usually be executed
directly or are collectively run by pypy/test_all.py
-- each test directory needs a copy of pypy/tool/autopath.py which
- upon import will make sure that sys.path contains the directory
.. _`change documentation and website`:
Changing documentation and website
.. _`ReST quickstart`: http://docutils.sourceforge.net/docs/user/rst/quickref.html
Note that the web site of http://pypy.org/ is maintained separately.
-For now it is in the repository https://bitbucket.org/pypy/extradoc
-in the directory ``pypy.org``.
+For now it is in the repository https://bitbucket.org/pypy/pypy.org
Automatically test documentation/website changes