Hi PyPy, just updated the website http://codespeak.net/pypy with some information about what happened at the PyPy-Sprint in Louvain-La-Neuve before EuroPython and at the conference itself. We got quite some attention at the EuroPython 2003 conference where Armin Rigo gave a pygame-based talk and Guido van Rossum was repeatedly seen hacking on PyPy. In his keynote he presented PyPy as a "very ambitious project", adding "It's just fun to work on it". OTOH, everyone was making fun of the fact that PyPy runs 20000 times slower than CPython :-) To bring everybody who is interested up-to-date with recent developments and discussions i am giving a bit of an overview on current developments. - the interpreter is now in pretty good shape. It works nicely with our three object spaces: Trivial dispatches object operations quite directly CPython objects. Standard implements the standard python type system (and methods) including Generators, __new__ methods and metaclasses. Annotation implements "abstract interpretation" which heads for inferencing types for function parameters and return values of a complete python program. this space will form the basis of the soon-to-come code-generator. which doesn't mean that there is not lots of refactoring and improvements on the current code base to do. - we decided to put our evolving documentation into the subversion respository instead of the wiki. This allows for more consistent documents and notifications about changes, versioning etc. Anna has done quite some work in that area. We are using the RestructeredText text format which is rendered into html on the codespeak server whenever documentation changes. - Laura is going forward to present PyPy at the OSCON 2003 and she together with help from other developers improved the paper. IIUC the paper should be transformed into ReST and further improved (i am somewhat starting to do that). - we discussed going for EU-funding. The general oppinion was that the current Call for Proposals fits the possible targets of PyPy pretty well. But going for EU-funding is by far a simple task. We have already talked to some companies and are also looking for research institutions that would want to participate in a big EU-Project. After some discussions especially with Armin i now think that we should promote as a goal to dynamically tie into/adapt arbritrary C-Libraries and operation system calls. The latter would basically mean that you could use Python directly to drive your favourite OS. Think rapidly specializing for whatever embedded device without even a libc and doing that with 99% of the code beeing written in Python. However, we only have three month to fullfill the EU-funding conditions. If we want to involve larger companies then we have to be very quick because large companies often take month to sign contracts. We are grateful for any hint or person you can recommend in order to support us with matching the EU requirements. In return, we can easily help you to envision usages of PyPy for your company or research institution :-) - the EU-funding will probably make it necessary to form some body representing the pypy developers among companies and researchers. The current idea is to setup a "pypy foundation" or even better "py fundation" which brings together three driving forces: Python, Fun & Funding. The latest date to found such an organization will be the next sprint (oh dear) ... - the next PyPy sprint will probably take place in Berlin end of september 2003. It's focus will probably be to emit C-Code in one way or another. After long discussions Samuele, Armin and me think that it's a good idea to target Pyrex as the first "emitted code" language. It has two advantages: - Pyrex handles garbage collection aka hairy details of refcounting and is a nice language to generate :-) - generating runnable CPython modules allows early (and faster!) testing. Basically we want to be able to import pypy as an extension module into CPython *taking over* interpretation of byte codes. - the test framework was improved further but needs more work in various areas. Michael and me even considered rewriting the unittest module alltogether because we need a fine-grained flexibilty regarding object spaces. Something like a test-coverage tool that tells us which code pathes in our programs are not tested. And I'd like a webpage which reports which revision broke which tests and some other nice reports (a nicely rendered commit-log for starters). - we currently have around 10000 lines of code (LOC) and 4 KLOC of tests. it is too early to compare these LOC to CPython's but it's nevertheless an interesting number. so far for now. have fun, holger