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

Troy Melhase troy at gci.net
Mon Feb 17 14:24:23 EST 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
here:

    http://codespeak.net/pipermail/pypy-dev/


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:

    http://codespeak.net/pipermail/pypy-dev/2003q1/000416.html


Wiki Content
------------

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000412.html


Reusing Parrot
--------------

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000413.html

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:

    http://codespeak.net/pipermail/pypy-dev/2003q1/000418.html


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:

    http://codespeak.net/pipermail/pypy-dev/2003q1/000425.html

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000426.html


Scons
-----

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000422.html

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000430.html

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000449.html


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
snapshots:

    http://codespeak.net/pipermail/pypy-dev/2003q1/000419.html

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000420.html

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000423.html


PyPy at OSCON
-------------

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000427.html

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:

    http://codespeak.net/pipermail/pypy-dev/2003q1/000436.html

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000429.html


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:

    http://codespeak.net/pipermail/pypy-dev/2003q1/000431.html

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000445.html

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000434.html

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000438.html

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000447.html

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:

    http://codespeak.net/pipermail/pypy-dev/2003q1/000448.html

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000456.html

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:

    http://codespeak.net/pipermail/pypy-dev/2003q1/000443.html


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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000450.html

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:

    http://codespeak.net/pipermail/pypy-dev/2003q1/000451.html

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000457.html

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
implementations:

    http://codespeak.net/pipermail/pypy-dev/2003q1/000460.html

Down Time
---------

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000453.html


Subverted
---------

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000454.html

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000458.html

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000463.html

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

    http://codespeak.net/pipermail/pypy-dev/2003q1/000455.html


Minimally,
-troy

More information about the Python-list mailing list