[pypy-dev] Re: [pypy-sprint] sprint quickly approaching

[Armin Rigo]

Hello,

Here are some info about the state of PyPy and what we expect to work on
during the upcoming sprint.

On annotations
--------------

There isn't much more than already described on the "Brainstorming" thread.
The annotations are implemented just as I wrote they should be.  It just
works, basically.  There are a few more SomeXxx classes than described in the
e-mails, like SomeClass, SomeInstance, and SomeMethod to analyse OOP programs.  
It should be quite easy to have an overview of what these mean just by reading
pypy.annotation.model.

So the current status is that we can analyse simple RPython programs.  The
next two things do be done in this direction and that should be put on the
sprint's schedule are:

* complete the Pyrex code writer; we are in the unlikely state where we can
analyse more stuff than we can actually write code for (e.g. methods in
classes).

* try to analyse larger programs, seeing if the time we need for the analysis 
remains reasonable or explodes.

We should give a try at analysing py.py's entry point itself and moving on as
numerous hard and unexpected problems pop up.  For example, we'll need a way
to tell the analysis/translator that some bits of PyPy are only lazy
computations of stuff that gets cached into a dictionary after the first use
(so that the translator should trigger the computation and just pick the value
from the cache instead of analysing the cache-populating code).

On objspace.std
---------------

The other thing we might put on our agenda is refactoring the object model
(i.e. objspace.std).  The multimethod thing is great but really hard to match
to the Python semantics of new-style classes and descriptors.  As far as I can
see, a reasonable way to rethink the problem would be to start from the usual
type-based semantics of Python, e.g. really defining a+b to mean a.__add__(b)
or if it fails b.__radd__(a).  The multimethod declarations would not be used
for dispatching, but only to initialize the proper __add__ and __radd__
methods on the proper classes.  This would give the cleanest result.

This would probably be slower than the current multimethod dispatch hack, but
being able to remove multimethod.py altogether is no small achievement in the
direction of clarity :-)  Then we could consider if we could reintroduce
direct multimethod-style dispatching as an optional optimization.

Well, just a thought.  Maybe it's not worth the effort right now.  There are
only a few constructs missing to be able to run most "common" programs, for
example super().  Defining super() at app-level Python should be possible, but
is not currently because the required details don't work as expected.  But we
could define super() at interp-level and just forget about the whole issue for
some time.

On modules
----------

As always there is the open goal of implementing more built-in functions and
modules, and making sure that more of the implemented features actually work.

As always, we have two big missing features: the bytecode compiler and the
import mechanism.

Note that an easy but interesting goal would be to isolate a version of py.py
that can be moved anywhere (as long as pypy is in the PYTHONPATH) and used as
a replacement for the python executable.  The first thing that usually fails
whenever I try to start py.py on some program is an import statement.  I'm not
sure what the state of sys.path & co is.

On everything I forget
----------------------

There are a lot of areas to work on too.  For example writing docs, the trace
object space, writing docs, more debugging support (kill these huge
tracebacks!), porting the tests to 'std.utest' (I'll let Holger introduce this
one to pypy-dev), organizing docs, cleaning up the wiki and replacing it with
ReST docs ...


A bientôt,

Armin