[pypy-svn] pypy documentation-cleanup: merge heads
arigo
commits-noreply at bitbucket.org
Sat Apr 30 14:15:01 CEST 2011
Author: Armin Rigo <arigo at tunes.org>
Branch: documentation-cleanup
Changeset: r43802:bea75c070193
Date: 2011-04-30 14:14 +0200
http://bitbucket.org/pypy/pypy/changeset/bea75c070193/
Log: merge heads
diff --git a/pypy/doc/getting-started-dev.rst b/pypy/doc/getting-started-dev.rst
--- a/pypy/doc/getting-started-dev.rst
+++ b/pypy/doc/getting-started-dev.rst
@@ -10,10 +10,9 @@
-------------------------
The translator is a tool based on the PyPy interpreter which can translate
-sufficiently static Python programs into low-level code (in particular it can
-be used to translate the `full Python interpreter`_). To be able to use it
-you need to (if you want to look at the flowgraphs, which you obviously
-should):
+sufficiently static RPython programs into low-level code (in particular it can
+be used to translate the `full Python interpreter`_). To be able to experiment with it
+you need to:
* Download and install Pygame_.
@@ -146,7 +145,7 @@
Where to start reading the sources
----------------------------------
-PyPy is made from parts that are relatively independent from each other.
+PyPy is made from parts that are relatively independent of each other.
You should start looking at the part that attracts you most (all paths are
relative to the PyPy top level directory). You may look at our `directory reference`_
or start off at one of the following points:
@@ -159,15 +158,13 @@
interpreter are defined in `pypy/interpreter/typedef.py`_.
* `pypy/interpreter/pyparser`_ contains a recursive descent parser,
- and input data files that allow it to parse the syntax of various Python
- versions. Once the input data has been processed, the parser can be
+ and grammar files that allow it to parse the syntax of various Python
+ versions. Once the grammar has been processed, the parser can be
translated by the above machinery into efficient code.
* `pypy/interpreter/astcompiler`_ contains the compiler. This
contains a modified version of the compiler package from CPython
- that fixes some bugs and is translatable. That the compiler and
- parser are translatable is new in 0.8.0 and it makes using the
- resulting binary interactively much more pleasant.
+ that fixes some bugs and is translatable.
* `pypy/objspace/std`_ contains the `Standard object space`_. The main file
is `pypy/objspace/std/objspace.py`_. For each type, the files ``xxxtype.py`` and
@@ -190,24 +187,25 @@
* `pypy/rpython`_ contains the code of the RPython typer. The typer transforms
annotated flow graphs in a way that makes them very similar to C code so
that they can be easy translated. The graph transformations are controlled
- by the stuff in `pypy/rpython/rtyper.py`_. The object model that is used can
+ by the code in `pypy/rpython/rtyper.py`_. The object model that is used can
be found in `pypy/rpython/lltypesystem/lltype.py`_. For each RPython type
there is a file rxxxx.py that contains the low level functions needed for
this type.
-* `pypy/rlib`_ contains the RPython standard library, things that you can
+* `pypy/rlib`_ contains the `RPython standard library`_, things that you can
use from rpython.
+.. _`RPython standard library`: rlib.html
+
.. _optionaltool:
Running PyPy's unit tests
-------------------------
-PyPy development always was and is still thorougly test-driven.
+PyPy development always was and is still thoroughly test-driven.
We use the flexible `py.test testing tool`_ which you can `install independently
-<http://pytest.org/getting-started.html>`_ and use indepedently
-from PyPy for other projects.
+<http://pytest.org/getting-started.html>`_ and use for other projects.
The PyPy source tree comes with an inlined version of ``py.test``
which you can invoke by typing::
@@ -355,7 +353,7 @@
We use the `py library`_ for filesystem path manipulations, terminal
writing, logging and some other support functionality.
-You don't neccessarily need to install these two libraries because
+You don't necessarily need to install these two libraries because
we also ship them inlined in the PyPy source tree.
Getting involved
diff --git a/pypy/doc/objspace-proxies.rst b/pypy/doc/objspace-proxies.rst
--- a/pypy/doc/objspace-proxies.rst
+++ b/pypy/doc/objspace-proxies.rst
@@ -18,10 +18,6 @@
only if and when needed; and a way to globally replace an object with
another.
-* *Taint Object Space*: a soft security system; your application cannot
- accidentally compute results based on tainted objects unless it
- explicitly untaints them first.
-
* *Dump Object Space*: dumps all operations performed on all the objects
into a large log file. For debugging your applications.
@@ -133,293 +129,295 @@
function behaves lazily: all calls to it return a thunk object.
-.. _taint:
+.. broken right now:
-The Taint Object Space
-======================
+ .. _taint:
-Motivation
-----------
+ The Taint Object Space
+ ======================
-The Taint Object Space provides a form of security: "tainted objects",
-inspired by various sources, see [D12.1]_ for a more detailed discussion.
+ Motivation
+ ----------
-The basic idea of this kind of security is not to protect against
-malicious code but to help with handling and boxing sensitive data.
-It covers two kinds of sensitive data: secret data which should not leak,
-and untrusted data coming from an external source and that must be
-validated before it is used.
+ The Taint Object Space provides a form of security: "tainted objects",
+ inspired by various sources, see [D12.1]_ for a more detailed discussion.
-The idea is that, considering a large application that handles these
-kinds of sensitive data, there are typically only a small number of
-places that need to explicitly manipulate that sensitive data; all the
-other places merely pass it around, or do entirely unrelated things.
+ The basic idea of this kind of security is not to protect against
+ malicious code but to help with handling and boxing sensitive data.
+ It covers two kinds of sensitive data: secret data which should not leak,
+ and untrusted data coming from an external source and that must be
+ validated before it is used.
-Nevertheless, if a large application needs to be reviewed for security,
-it must be entirely carefully checked, because it is possible that a
-bug at some apparently unrelated place could lead to a leak of sensitive
-information in a way that an external attacker could exploit. For
-example, if any part of the application provides web services, an
-attacker might be able to issue unexpected requests with a regular web
-browser and deduce secret information from the details of the answers he
-gets. Another example is the common CGI attack where an attacker sends
-malformed inputs and causes the CGI script to do unintended things.
+ The idea is that, considering a large application that handles these
+ kinds of sensitive data, there are typically only a small number of
+ places that need to explicitly manipulate that sensitive data; all the
+ other places merely pass it around, or do entirely unrelated things.
-An approach like that of the Taint Object Space allows the small parts
-of the program that manipulate sensitive data to be explicitly marked.
-The effect of this is that although these small parts still need a
-careful security review, the rest of the application no longer does,
-because even a bug would be unable to leak the information.
+ Nevertheless, if a large application needs to be reviewed for security,
+ it must be entirely carefully checked, because it is possible that a
+ bug at some apparently unrelated place could lead to a leak of sensitive
+ information in a way that an external attacker could exploit. For
+ example, if any part of the application provides web services, an
+ attacker might be able to issue unexpected requests with a regular web
+ browser and deduce secret information from the details of the answers he
+ gets. Another example is the common CGI attack where an attacker sends
+ malformed inputs and causes the CGI script to do unintended things.
-We have implemented a simple two-level model: objects are either
-regular (untainted), or sensitive (tainted). Objects are marked as
-sensitive if they are secret or untrusted, and only declassified at
-carefully-checked positions (e.g. where the secret data is needed, or
-after the untrusted data has been fully validated).
+ An approach like that of the Taint Object Space allows the small parts
+ of the program that manipulate sensitive data to be explicitly marked.
+ The effect of this is that although these small parts still need a
+ careful security review, the rest of the application no longer does,
+ because even a bug would be unable to leak the information.
-It would be simple to extend the code for more fine-grained scales of
-secrecy. For example it is typical in the literature to consider
-user-specified lattices of secrecy levels, corresponding to multiple
-"owners" that cannot access data belonging to another "owner" unless
-explicitly authorized to do so.
+ We have implemented a simple two-level model: objects are either
+ regular (untainted), or sensitive (tainted). Objects are marked as
+ sensitive if they are secret or untrusted, and only declassified at
+ carefully-checked positions (e.g. where the secret data is needed, or
+ after the untrusted data has been fully validated).
-Tainting and untainting
------------------------
+ It would be simple to extend the code for more fine-grained scales of
+ secrecy. For example it is typical in the literature to consider
+ user-specified lattices of secrecy levels, corresponding to multiple
+ "owners" that cannot access data belonging to another "owner" unless
+ explicitly authorized to do so.
-Start a py.py with the Taint Object Space and try the following example::
+ Tainting and untainting
+ -----------------------
- $ py.py -o taint
- >>>> from __pypy__ import taint
- >>>> x = taint(6)
+ Start a py.py with the Taint Object Space and try the following example::
- # x is hidden from now on. We can pass it around and
- # even operate on it, but not inspect it. Taintness
- # is propagated to operation results.
+ $ py.py -o taint
+ >>>> from __pypy__ import taint
+ >>>> x = taint(6)
- >>>> x
- TaintError
+ # x is hidden from now on. We can pass it around and
+ # even operate on it, but not inspect it. Taintness
+ # is propagated to operation results.
- >>>> if x > 5: y = 2 # see below
- TaintError
+ >>>> x
+ TaintError
- >>>> y = x + 5 # ok
- >>>> lst = [x, y]
- >>>> z = lst.pop()
- >>>> t = type(z) # type() works too, tainted answer
- >>>> t
- TaintError
- >>>> u = t is int # even 'is' works
- >>>> u
- TaintError
+ >>>> if x > 5: y = 2 # see below
+ TaintError
-Notice that using a tainted boolean like ``x > 5`` in an ``if``
-statement is forbidden. This is because knowing which path is followed
-would give away a hint about ``x``; in the example above, if the
-statement ``if x > 5: y = 2`` was allowed to run, we would know
-something about the value of ``x`` by looking at the (untainted) value
-in the variable ``y``.
+ >>>> y = x + 5 # ok
+ >>>> lst = [x, y]
+ >>>> z = lst.pop()
+ >>>> t = type(z) # type() works too, tainted answer
+ >>>> t
+ TaintError
+ >>>> u = t is int # even 'is' works
+ >>>> u
+ TaintError
-Of course, there is a way to inspect tainted objects. The basic way is
-to explicitly "declassify" it with the ``untaint()`` function. In an
-application, the places that use ``untaint()`` are the places that need
-careful security review. To avoid unexpected objects showing up, the
-``untaint()`` function must be called with the exact type of the object
-to declassify. It will raise ``TaintError`` if the type doesn't match::
+ Notice that using a tainted boolean like ``x > 5`` in an ``if``
+ statement is forbidden. This is because knowing which path is followed
+ would give away a hint about ``x``; in the example above, if the
+ statement ``if x > 5: y = 2`` was allowed to run, we would know
+ something about the value of ``x`` by looking at the (untainted) value
+ in the variable ``y``.
- >>>> from __pypy__ import taint
- >>>> untaint(int, x)
- 6
- >>>> untaint(int, z)
- 11
- >>>> untaint(bool, x > 5)
- True
- >>>> untaint(int, x > 5)
- TaintError
+ Of course, there is a way to inspect tainted objects. The basic way is
+ to explicitly "declassify" it with the ``untaint()`` function. In an
+ application, the places that use ``untaint()`` are the places that need
+ careful security review. To avoid unexpected objects showing up, the
+ ``untaint()`` function must be called with the exact type of the object
+ to declassify. It will raise ``TaintError`` if the type doesn't match::
+ >>>> from __pypy__ import taint
+ >>>> untaint(int, x)
+ 6
+ >>>> untaint(int, z)
+ 11
+ >>>> untaint(bool, x > 5)
+ True
+ >>>> untaint(int, x > 5)
+ TaintError
-Taint Bombs
------------
-In this area, a common problem is what to do about failing operations.
-If an operation raises an exception when manipulating a tainted object,
-then the very presence of the exception can leak information about the
-tainted object itself. Consider::
+ Taint Bombs
+ -----------
- >>>> 5 / (x-6)
+ In this area, a common problem is what to do about failing operations.
+ If an operation raises an exception when manipulating a tainted object,
+ then the very presence of the exception can leak information about the
+ tainted object itself. Consider::
-By checking if this raises ``ZeroDivisionError`` or not, we would know
-if ``x`` was equal to 6 or not. The solution to this problem in the
-Taint Object Space is to introduce *Taint Bombs*. They are a kind of
-tainted object that doesn't contain a real object, but a pending
-exception. Taint Bombs are indistinguishable from normal tainted
-objects to unprivileged code. See::
+ >>>> 5 / (x-6)
- >>>> x = taint(6)
- >>>> i = 5 / (x-6) # no exception here
- >>>> j = i + 1 # nor here
- >>>> k = j + 5 # nor here
- >>>> untaint(int, k)
- TaintError
+ By checking if this raises ``ZeroDivisionError`` or not, we would know
+ if ``x`` was equal to 6 or not. The solution to this problem in the
+ Taint Object Space is to introduce *Taint Bombs*. They are a kind of
+ tainted object that doesn't contain a real object, but a pending
+ exception. Taint Bombs are indistinguishable from normal tainted
+ objects to unprivileged code. See::
-In the above example, all of ``i``, ``j`` and ``k`` contain a Taint
-Bomb. Trying to untaint it raises an exception - a generic
-``TaintError``. What we win is that the exception gives little away,
-and most importantly it occurs at the point where ``untaint()`` is
-called, not where the operation failed. This means that all calls to
-``untaint()`` - but not the rest of the code - must be carefully
-reviewed for what occurs if they receive a Taint Bomb; they might catch
-the ``TaintError`` and give the user a generic message that something
-went wrong, if we are reasonably careful that the message or even its
-presence doesn't give information away. This might be a
-problem by itself, but there is no satisfying general solution here:
-it must be considered on a case-by-case basis. Again, what the
-Taint Object Space approach achieves is not solving these problems, but
-localizing them to well-defined small parts of the application - namely,
-around calls to ``untaint()``.
+ >>>> x = taint(6)
+ >>>> i = 5 / (x-6) # no exception here
+ >>>> j = i + 1 # nor here
+ >>>> k = j + 5 # nor here
+ >>>> untaint(int, k)
+ TaintError
-The ``TaintError`` exception deliberately does not include any
-useful error messages, because they might give information away.
-Of course, this makes debugging quite a bit harder; a difficult
-problem to solve properly. So far we have implemented a way to peek in a Taint
-Box or Bomb, ``__pypy__._taint_look(x)``, and a "debug mode" that
-prints the exception as soon as a Bomb is created - both write
-information to the low-level stderr of the application, where we hope
-that it is unlikely to be seen by anyone but the application
-developer.
+ In the above example, all of ``i``, ``j`` and ``k`` contain a Taint
+ Bomb. Trying to untaint it raises an exception - a generic
+ ``TaintError``. What we win is that the exception gives little away,
+ and most importantly it occurs at the point where ``untaint()`` is
+ called, not where the operation failed. This means that all calls to
+ ``untaint()`` - but not the rest of the code - must be carefully
+ reviewed for what occurs if they receive a Taint Bomb; they might catch
+ the ``TaintError`` and give the user a generic message that something
+ went wrong, if we are reasonably careful that the message or even its
+ presence doesn't give information away. This might be a
+ problem by itself, but there is no satisfying general solution here:
+ it must be considered on a case-by-case basis. Again, what the
+ Taint Object Space approach achieves is not solving these problems, but
+ localizing them to well-defined small parts of the application - namely,
+ around calls to ``untaint()``.
+ The ``TaintError`` exception deliberately does not include any
+ useful error messages, because they might give information away.
+ Of course, this makes debugging quite a bit harder; a difficult
+ problem to solve properly. So far we have implemented a way to peek in a Taint
+ Box or Bomb, ``__pypy__._taint_look(x)``, and a "debug mode" that
+ prints the exception as soon as a Bomb is created - both write
+ information to the low-level stderr of the application, where we hope
+ that it is unlikely to be seen by anyone but the application
+ developer.
-Taint Atomic functions
-----------------------
-Occasionally, a more complicated computation must be performed on a
-tainted object. This requires first untainting the object, performing the
-computations, and then carefully tainting the result again (including
-hiding all exceptions into Bombs).
+ Taint Atomic functions
+ ----------------------
-There is a built-in decorator that does this for you::
+ Occasionally, a more complicated computation must be performed on a
+ tainted object. This requires first untainting the object, performing the
+ computations, and then carefully tainting the result again (including
+ hiding all exceptions into Bombs).
- >>>> @__pypy__.taint_atomic
- >>>> def myop(x, y):
- .... while x > 0:
- .... x -= y
- .... return x
- ....
- >>>> myop(42, 10)
- -8
- >>>> z = myop(taint(42), 10)
- >>>> z
- TaintError
- >>>> untaint(int, z)
- -8
+ There is a built-in decorator that does this for you::
-The decorator makes a whole function behave like a built-in operation.
-If no tainted argument is passed in, the function behaves normally. But
-if any of the arguments is tainted, it is automatically untainted - so
-the function body always sees untainted arguments - and the eventual
-result is tainted again (possibly in a Taint Bomb).
+ >>>> @__pypy__.taint_atomic
+ >>>> def myop(x, y):
+ .... while x > 0:
+ .... x -= y
+ .... return x
+ ....
+ >>>> myop(42, 10)
+ -8
+ >>>> z = myop(taint(42), 10)
+ >>>> z
+ TaintError
+ >>>> untaint(int, z)
+ -8
-It is important for the function marked as ``taint_atomic`` to have no
-visible side effects, as these could cause information leakage.
-This is currently not enforced, which means that all ``taint_atomic``
-functions have to be carefully reviewed for security (but not the
-callers of ``taint_atomic`` functions).
+ The decorator makes a whole function behave like a built-in operation.
+ If no tainted argument is passed in, the function behaves normally. But
+ if any of the arguments is tainted, it is automatically untainted - so
+ the function body always sees untainted arguments - and the eventual
+ result is tainted again (possibly in a Taint Bomb).
-A possible future extension would be to forbid side-effects on
-non-tainted objects from all ``taint_atomic`` functions.
+ It is important for the function marked as ``taint_atomic`` to have no
+ visible side effects, as these could cause information leakage.
+ This is currently not enforced, which means that all ``taint_atomic``
+ functions have to be carefully reviewed for security (but not the
+ callers of ``taint_atomic`` functions).
-An example of usage: given a tainted object ``passwords_db`` that
-references a database of passwords, we can write a function
-that checks if a password is valid as follows::
+ A possible future extension would be to forbid side-effects on
+ non-tainted objects from all ``taint_atomic`` functions.
- @taint_atomic
- def validate(passwords_db, username, password):
- assert type(passwords_db) is PasswordDatabase
- assert type(username) is str
- assert type(password) is str
- ...load username entry from passwords_db...
- return expected_password == password
+ An example of usage: given a tainted object ``passwords_db`` that
+ references a database of passwords, we can write a function
+ that checks if a password is valid as follows::
-It returns a tainted boolean answer, or a Taint Bomb if something
-went wrong. A caller can do::
+ @taint_atomic
+ def validate(passwords_db, username, password):
+ assert type(passwords_db) is PasswordDatabase
+ assert type(username) is str
+ assert type(password) is str
+ ...load username entry from passwords_db...
+ return expected_password == password
- ok = validate(passwords_db, 'john', '1234')
- ok = untaint(bool, ok)
+ It returns a tainted boolean answer, or a Taint Bomb if something
+ went wrong. A caller can do::
-This can give three outcomes: ``True``, ``False``, or a ``TaintError``
-exception (with no information on it) if anything went wrong. If even
-this is considered giving too much information away, the ``False`` case
-can be made indistinguishable from the ``TaintError`` case (simply by
-raising an exception in ``validate()`` if the password is wrong).
+ ok = validate(passwords_db, 'john', '1234')
+ ok = untaint(bool, ok)
-In the above example, the security results achieved are the following:
-as long as ``validate()`` does not leak information, no other part of
-the code can obtain more information about a passwords database than a
-Yes/No answer to a precise query.
+ This can give three outcomes: ``True``, ``False``, or a ``TaintError``
+ exception (with no information on it) if anything went wrong. If even
+ this is considered giving too much information away, the ``False`` case
+ can be made indistinguishable from the ``TaintError`` case (simply by
+ raising an exception in ``validate()`` if the password is wrong).
-A possible extension of the ``taint_atomic`` decorator would be to check
-the argument types, as ``untaint()`` does, for the same reason: to
-prevent bugs where a function like ``validate()`` above is accidentally
-called with the wrong kind of tainted object, which would make it
-misbehave. For now, all ``taint_atomic`` functions should be
-conservative and carefully check all assumptions on their input
-arguments.
+ In the above example, the security results achieved are the following:
+ as long as ``validate()`` does not leak information, no other part of
+ the code can obtain more information about a passwords database than a
+ Yes/No answer to a precise query.
+ A possible extension of the ``taint_atomic`` decorator would be to check
+ the argument types, as ``untaint()`` does, for the same reason: to
+ prevent bugs where a function like ``validate()`` above is accidentally
+ called with the wrong kind of tainted object, which would make it
+ misbehave. For now, all ``taint_atomic`` functions should be
+ conservative and carefully check all assumptions on their input
+ arguments.
-.. _`taint-interface`:
-Interface
----------
+ .. _`taint-interface`:
-.. _`like a built-in operation`:
+ Interface
+ ---------
-The basic rule of the Tainted Object Space is that it introduces two new
-kinds of objects, Tainted Boxes and Tainted Bombs (which are not types
-in the Python sense). Each box internally contains a regular object;
-each bomb internally contains an exception object. An operation
-involving Tainted Boxes is performed on the objects contained in the
-boxes, and gives a Tainted Box or a Tainted Bomb as a result (such an
-operation does not let an exception be raised). An operation called
-with a Tainted Bomb argument immediately returns the same Tainted Bomb.
+ .. _`like a built-in operation`:
-In a PyPy running with (or translated with) the Taint Object Space,
-the ``__pypy__`` module exposes the following interface:
+ The basic rule of the Tainted Object Space is that it introduces two new
+ kinds of objects, Tainted Boxes and Tainted Bombs (which are not types
+ in the Python sense). Each box internally contains a regular object;
+ each bomb internally contains an exception object. An operation
+ involving Tainted Boxes is performed on the objects contained in the
+ boxes, and gives a Tainted Box or a Tainted Bomb as a result (such an
+ operation does not let an exception be raised). An operation called
+ with a Tainted Bomb argument immediately returns the same Tainted Bomb.
-* ``taint(obj)``
+ In a PyPy running with (or translated with) the Taint Object Space,
+ the ``__pypy__`` module exposes the following interface:
- Return a new Tainted Box wrapping ``obj``. Return ``obj`` itself
- if it is already tainted (a Box or a Bomb).
+ * ``taint(obj)``
-* ``is_tainted(obj)``
+ Return a new Tainted Box wrapping ``obj``. Return ``obj`` itself
+ if it is already tainted (a Box or a Bomb).
- Check if ``obj`` is tainted (a Box or a Bomb).
+ * ``is_tainted(obj)``
-* ``untaint(type, obj)``
+ Check if ``obj`` is tainted (a Box or a Bomb).
- Untaints ``obj`` if it is tainted. Raise ``TaintError`` if the type
- of the untainted object is not exactly ``type``, or if ``obj`` is a
- Bomb.
+ * ``untaint(type, obj)``
-* ``taint_atomic(func)``
+ Untaints ``obj`` if it is tainted. Raise ``TaintError`` if the type
+ of the untainted object is not exactly ``type``, or if ``obj`` is a
+ Bomb.
- Return a wrapper function around the callable ``func``. The wrapper
- behaves `like a built-in operation`_ with respect to untainting the
- arguments, tainting the result, and returning a Bomb.
+ * ``taint_atomic(func)``
-* ``TaintError``
+ Return a wrapper function around the callable ``func``. The wrapper
+ behaves `like a built-in operation`_ with respect to untainting the
+ arguments, tainting the result, and returning a Bomb.
- Exception. On purpose, it provides no attribute or error message.
+ * ``TaintError``
-* ``_taint_debug(level)``
+ Exception. On purpose, it provides no attribute or error message.
- Set the debugging level to ``level`` (0=off). At level 1 or above,
- all Taint Bombs print a diagnostic message to stderr when they are
- created.
+ * ``_taint_debug(level)``
-* ``_taint_look(obj)``
+ Set the debugging level to ``level`` (0=off). At level 1 or above,
+ all Taint Bombs print a diagnostic message to stderr when they are
+ created.
- For debugging purposes: prints (to stderr) the type and address of
- the object in a Tainted Box, or prints the exception if ``obj`` is
- a Taint Bomb.
+ * ``_taint_look(obj)``
+
+ For debugging purposes: prints (to stderr) the type and address of
+ the object in a Tainted Box, or prints the exception if ``obj`` is
+ a Taint Bomb.
.. _dump:
diff --git a/pypy/doc/index.rst b/pypy/doc/index.rst
--- a/pypy/doc/index.rst
+++ b/pypy/doc/index.rst
@@ -273,8 +273,6 @@
`pypy/objspace/dump.py`_ the dump object space saves a large, searchable log file
with all operations
-`pypy/objspace/taint.py`_ the `taint object space`_, providing object tainting
-
`pypy/objspace/thunk.py`_ the `thunk object space`_, providing unique object features
`pypy/objspace/flow/`_ the FlowObjSpace_ implementing `abstract interpretation`_
diff --git a/pypy/doc/__pypy__-module.rst b/pypy/doc/__pypy__-module.rst
--- a/pypy/doc/__pypy__-module.rst
+++ b/pypy/doc/__pypy__-module.rst
@@ -37,27 +37,29 @@
.. _`thunk object space docs`: objspace-proxies.html#thunk
.. _`interface section of the thunk object space docs`: objspace-proxies.html#thunk-interface
-Taint Object Space Functionality
-================================
+.. broken:
-When the taint object space is used (choose with :config:`objspace.name`),
-the following names are put into ``__pypy__``:
+ Taint Object Space Functionality
+ ================================
- - ``taint``
- - ``is_tainted``
- - ``untaint``
- - ``taint_atomic``
- - ``_taint_debug``
- - ``_taint_look``
- - ``TaintError``
+ When the taint object space is used (choose with :config:`objspace.name`),
+ the following names are put into ``__pypy__``:
-Those are all described in the `interface section of the taint object space
-docs`_.
+ - ``taint``
+ - ``is_tainted``
+ - ``untaint``
+ - ``taint_atomic``
+ - ``_taint_debug``
+ - ``_taint_look``
+ - ``TaintError``
-For more detailed explanations and examples see the `taint object space docs`_.
+ Those are all described in the `interface section of the taint object space
+ docs`_.
-.. _`taint object space docs`: objspace-proxies.html#taint
-.. _`interface section of the taint object space docs`: objspace-proxies.html#taint-interface
+ For more detailed explanations and examples see the `taint object space docs`_.
+
+ .. _`taint object space docs`: objspace-proxies.html#taint
+ .. _`interface section of the taint object space docs`: objspace-proxies.html#taint-interface
Transparent Proxy Functionality
===============================
diff --git a/pypy/doc/interpreter.rst b/pypy/doc/interpreter.rst
--- a/pypy/doc/interpreter.rst
+++ b/pypy/doc/interpreter.rst
@@ -146,21 +146,15 @@
file location can be constructed for tracebacks
Moreover the Frame class itself has a number of methods which implement
-the actual bytecodes found in a code object. In fact, PyPy already constructs
-four specialized Frame class variants depending on the code object:
+the actual bytecodes found in a code object. The methods of the ``PyFrame``
+class are added in various files:
-- PyInterpFrame (in `pypy/interpreter/pyopcode.py`_) for
- basic simple code objects (not involving generators or nested scopes)
+- the class ``PyFrame`` is defined in `pypy/interpreter/pyframe.py`_.
-- PyNestedScopeFrame (in `pypy/interpreter/nestedscope.py`_)
- for code objects that reference nested scopes, inherits from PyInterpFrame
+- the file `pypy/interpreter/pyopcode.py`_ add support for all Python opcode.
-- PyGeneratorFrame (in `pypy/interpreter/generator.py`_)
- for code objects that yield values to the caller, inherits from PyInterpFrame
-
-- PyNestedScopeGeneratorFrame for code objects that reference
- nested scopes and yield values to the caller, inherits from both PyNestedScopeFrame
- and PyGeneratorFrame
+- nested scope support is added to the ``PyFrame`` class in
+ `pypy/interpreter/nestedscope.py`_.
.. _Code:
More information about the Pypy-commit
mailing list