pypy-dev List Summary - 09 Feb 2003 to 16 Feb 2003

Troy Melhase troy at
Mon Feb 17 20:24:23 CET 2003

This is a summary of the discussions on the pypy-dev mailing list between 09
February and 16 February 2003.  The full archive of the list can be found

ZODB and Threads

In a continuation from last weeks thread discussing multiple VMs in a single
process, Jeremy Hylton says multi-threaded ZODB applications can use
multiple connections.  His response prompts Tobias Oberstein to share his
belief that the GIL is the real issue.  He suggests a replacement as well:

Wiki Content

Armin Rigo posts links to summaries he has created in the wiki:

Reusing Parrot

Tobias Oberstein brings up his recent discovery of the Parrot VM:

Lalo Martins thinks Parrot isn't relevent because it would only provide a
different VM.  Christian Tismer concurs that it wouldn't be useful, instead
because the VM isn't yet finished:

Generating C

Steven Shaw suggests that Minimal Python could generate C code, compile it,
and load it at runtime.  He cites Goo and GCL as examples:

Chris responds by saying C code is already a backend target, and that Psyco
would probably be faster:


Holger Krekel asks the list readers for opinions on Scons.  Chris says he
has been quite satisfied with it:

Charles Crain, a Scons developer, says Scons is "'technically' in alpha" but
extremely stable and well-tested:

Bram Moolenaar, lead developer of A-A-P, suggests A-A-P as an alternative
and lists the similarities and differences between the two:

Sprint Updates

VanL asks if sprint materials can be made available during the sprint.  He
asks for recordings of the talks, presentation materials, and nightly code

Chris says daily updates will go in the wiki, that the code will be
available, and that Dinu Gherman will probably write an article:

Bengt Richter asks for mp3s, and Dinu suggests AV streams:


Laura Creighton asks the list readers if anyone will be presenting or
speaking at OSCON:

Chris says he's going to PyCON and can't attend both.  Holger says he
doesn't know if he's going and suggests Laura do the presentation:

Laura proposes a report on the PyPy sprint and the project:

Object Model

Armin discusses his reorganized thoughts regarding the distinction between
"application-level" and "interpreter-level" objects.  He now believes in
following the lead of the CPython main loop by not assuming anything about
the objects upon which it operates.

He suggests implementing an 'ObjectSpace' class and making its instances
attributes of frame objects.  These 'objectspace' attributes would be
invisible to the application and would define the "library" needed to
perform the operations of the interpreter.  The objectspaces would define
'add', 'getitem', and more, in addition to 'wrap' and 'unwrap' methods:

Michael Hudson likes the idea, and Armin explains that exceptions need to be
caught in the objectspaces:

VanL asks for clarification by drawing analogies from his hardware
background, and Armin thinks his analogy is interesting and coherent:

Samuele Pedroni thinks the freedom provided by this approach also means
increased duplication:

Armin believes this can be mitigated by a multi-method-dispatch mechanism in
an abstract class:

Rocco Moretti wonders if 'wrap' and 'unwrap' would be necessary, and Armin
makes compelling arguments for them despite the drawbacks.  Armin likes the
symmetry between 'wrap' and 'unwrap' for a 'default' implementation, and
thinks the two methods could be the basis of network objectspaces:

Armin follows up to his own post by suggesting type-based dispatch may be
useful, and that both approaches should be tried:

VanL asks if bytecode semantics are to be preserved with the same rigor as
language semantics.  He wonders if a register-based VM could replace the
stack-based approach.  Paolo Invernizzi believes different VM
implementations are possible:

Memory Management
Richard Emslie broaches the subject of memory management.  He wonders how
PyPy will handle bytes at a lower level:

Chris responds that the intent is to not reimplement the the CPython GC, as
it is overly visible in CPython.  He lists the ways it encumbers the C
source and describes alternate object-referencing semantics:

Holger asks for clarification on the different algorithmic view of INCREF
and DECREF, and Armin uses parameter passing as an example:

Chris says INCREF and DECREF aren't wanted, but instead a method to increase
and decrease the "liveliness" of an object.  He thinks one approach may be
C-style automatic variables, but reminds that it's only one of many possible

Down Time

Holger sends notice that, the PyPy site and lists will be down
while the hardware is moved to the sprint location:


Holger announces Subversion as the planned source-control platform for PyPy:

Armin points out that Subversion must be downloaded twice to bootstrap
itself, and hopes that PyPy will be more efficient:

Chris asks if CVS would be a better choice, but Holger thinks Subversion
should be tried for the sprint:

Laura Creighton adds that Internet Explorer(tm) users can connect to the
Tigris SVN:


More information about the Python-list mailing list