[pypy-dev] website update / pypy developments

[holger krekel]

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