Antonio Cuni  committed 4180022

update the coding guide

  • Participants
  • Parent commits 9e4aa45
  • Branches documentation-cleanup

Comments (0)

Files changed (1)

File pypy/doc/coding-guide.rst

 whether a particular function is implemented at application or
 interpreter level. 
-our runtime interpreter is "restricted python"
+Our runtime interpreter is "RPython"
 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.
-Restricted Python
 RPython Definition, not
 .. _`wrapped`:
-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  ````
-* 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
-you can use the tool. 
-.. _Pylint:
-.. _logilab-common:
-.. _astng:
 Wrapping rules
     >>>> import sys
     >>>> sys.__file__
-    '/home/hpk/pypy-dist/pypy/module/sys/*.py'
+    '/home/hpk/pypy-dist/pypy/module/sys'
-    >>>> import operator
-    >>>> operator.__file__
-    '/home/hpk/pypy-dist/lib_pypy/'
+    >>>> import cPickle
+    >>>> cPickle.__file__
+    '/home/hpk/pypy-dist/lib_pypy/'
     >>>> import opcode
     >>>> opcode.__file__
-    '/home/hpk/pypy-dist/lib-python/modified-2.5.2/'
+    '/home/hpk/pypy-dist/lib-python/modified-2.7/'
     >>>> import os
-    faking <type 'posix.stat_result'>
-    faking <type 'posix.statvfs_result'>
     >>>> os.__file__
-    '/home/hpk/pypy-dist/lib-python/2.5.2/'
+    '/home/hpk/pypy-dist/lib-python/2.7/'
 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/ lib-python/modified-2.5.2/
+    $ hg cp lib-python/2.7/ lib-python/modified-2.7/
 and subsequently you edit and commit
-``lib-python/modified-2.5.2/``.  This copying operation is
+``lib-python/modified-2.7/``.  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
-the tracker`_ easily.
-modifying Issues from hg commit messages
-XXX: to be written after migrating the issue tracker away from
+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`:
 Testing in PyPy
-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`:
   python file_or_directory
 which is a synonym for the general `py.test`_ utility
-located in the ``pypy`` directory.  For switches to
+located in the ``py/bin/`` directory.  For switches to
 modify test execution pass the ``-h`` option.
 Test conventions
   which contain unittests.  Such scripts can usually be executed
   directly or are collectively run by pypy/
-- each test directory needs a copy of pypy/tool/ which
-  upon import will make sure that sys.path contains the directory
-  where 'pypy' is in.
 .. _`change documentation and website`:
 Changing documentation and website
 .. _`ReST quickstart`:
 Note that the web site of is maintained separately.
-For now it is in the repository
-in the directory ````.
+For now it is in the repository
 Automatically test documentation/website changes