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