[pypy-dev] pypy-dev List Summary - 06 Jan 2003 to 31 Jan 2003

Troy Melhase troy at gci.net
Thu Feb 6 08:39:48 CET 2003 

This is a summary of the discussions on the pypy-dev mailing list between 06
January and 31 January 2003.  The full archive of the list can be found here:

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


Bootstrapping
-------------

Holger Krekel starts the discussion in earnest with a message regarding how 
the project came about, and how to get Minimal Python[1] bootstrapped.  Robin
Becker suggests implementing the ctypes module.  Thomas Heller posts a working
version using libffi, and the possibility of using ffcall is also mentioned.
Christian Tismer would rather use the essential ideas of ctypes, rather than
the module itself, to keep Minimal Python small:

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

The build environment is discussed in this thread; CPython, SCons, make and
friends, and Builtool are mentioned.


C Core, Macros
--------------

Florian Schulze asks about plans for the C core.  Christian says most objects
will be borrowed at first.  Andrew McGregor brings up macros, and a lively
discussion ensues.  The consensus is that macros have already been rejected by
the BDFL, and implementing them would conflict with the project goal of
maintaining conformance with the language definition:

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


Ouroboros
---------

Damien Morton suggests using the ouroboros as the basis for the project logo.
In his words:  "In mythology, the Ouroboros is any image of a snake, worm,
serpent, or dragon biting its own tail."  He posts links and descriptions,
and Holger wants to add a bit of cuteness and fun:

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


Intellectual Property
---------------------

David Ascher wants the issues of IP and license resolved earlier rather than
later.  He suggests the IP be assigned to the PSF, and that the license be
PSF or AFL:

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


Road Map
---------

Bengt Richter suggests a project road map, and Guido responds with a quick 
list
of Python-already-implemented-in-Python.  Christian thanks him, and suggests
that Python code devoid of trickery is more suitable to Psyco.  Armin Rigo
agrees:

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

You tricksters know who you are!


PyVM
----

Paul Swartz posts a link to his PyVM, a Python Bytecode interpreter.

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


Project Name
------------

Many suggestions for an official project name were posted to the list 
throughout the month.  In lieu of listing them all (and surely omitting 
some), the summary is that there is no official name yet.  "Minimal Python" 
and "PyPython" are used commonly.


Compile.c
----------

Holger wonders aloud how to remove the need for compile.c, and talks about a
multi-stage VM:

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


Psyco in Python
---------------

Edward K. Ream asks how Psyco will fit in Minimal Python.  Michael Hudson and
Christian do their best to answer him, and mention the tantalizing possibility
of having Psyco re-implemented in Python:

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


Lessons from Experience
-----------------------

Rocco Moretti talks about his experience trying to write a Python interpreter
in Python.  He mentions the difficulty distinguishing between host and target,
and that use of Exceptions in CPython gave him trouble.  Christian advocates 
the generated-C approach, and Armin believes in separating application from
interpreter Exceptions:

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


Low-Level Data Type Representation
----------------------------------

Christian, Samuele Pedroni and Paul Rubin discuss various approaches on
representing low-level data types in at the much-higher Python level.  Paul
suggests tagged representation, Christian expresses the need to keep the types
easily deduced by the interpreter,  and Samuele suggests the boxed values
approach.  Guido chimes in with his first-hand knowledge of tagged
representation in the ABC language:

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


From PyPy to Psyco
------------------

Armin revisits the first goal of the project, writing a Python interpreter in
Python.  From there, he suggests, the "interesting things" are possible.  This
interpreter can be statically analyzed, and from the analysis will come a
minimal compiled interpreter, a bytecode checker, and Psyco:

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

Edward K. Ream responds with his interpretations and suggestions for making
Armin's tools available sooner.


Ported Psyco
------------

The subject of Psyco on non-x86 hardware comes up, and Armin says the newer
code will be flexible and easy to port:

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


Leo Outlines and Questions 
--------------------------

Edward K. Ream posts links to Leo outlines he's made for Psyco and for a C 
tool suite.

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

Edward also suggests that Psyco can't be faster than compiled C, and Armin
reminds him that it's a matter of perspective.  Agreement is quickly reached
that the point isn't relevant to the project:

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


More Questions
--------------

Edward is full of questions, and Armin has answers for him.  Armin casts more
light on Psyco, and his illumination deserves special note:

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

Bengt Richter brings up the idea of check-pointing Psyco code, and he and
Edward discuss storing the code in .pyp files.  Armin likes the idea, and
thinks it might be done outside of Psyco:

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


Restricted Language
-------------------

Christian poses many questions regarding the initial restricted language.
Discussion turns quickly to types:

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

Armin clarifies the issue by drawing a distinction between Python at the
interpreter-level and Python at the application-level:

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

Later in the thread, Scott David Daniels advises watching for boundary
conditions, and advocates a check-pointing system:

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

Armin revisits the need for a different approach to exception handling:

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


Implementation Language Questions
----------------------------------

Stephan Diehl asks why the implementation could not be written in Objective C.
Christian responds that the idea is to remove C, not to replace it:

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


Translating CPython Source
--------------------------

Christian speaks from experience when he says translating CPython source and
also maintaining concurrency with it is a loosing proposition.  As an
alternative, he suggests reusing portions of a C compiler package to provide a
level of automated translation of CPython source:

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

Edward advises changing perspective such that the problem goes away.  Thomas
Heller suggests that folks pick up a CPython module or two and translate them
into Python.

Holger believes maintaining two sources, CPython and PyPython would be a
nightmare, and Armin mentions Stackless and Jython as examples of the inherent
difficulty of implementing Python from translated CPython.  Armin believes the
translation could be automatic for most changes to CPython given an 
association between custom .py files and the CPython source.


Microthreads
------------

Sebastien Pierre asks if microthreads will be incorporated, and Armin says 
they would be easy enough, given a high-level description of the interpreter:

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


Minimal Sprint
--------------

Armin asks if there are definite dates for the first sprint.  Holger suggests
the 17th to the 23rd of February, and lists a possible location in Hildesheim:

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

Holger later announces the Minimal Python Sprint.  He cites the dates above,
and the goals of the sprint:

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


C Emissions
-----------

Logistix asks for clarification regarding the progression from byte code to C
to assembly.  Armin describes the two processes discussed so far:

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


CPython - PyPython
------------------

Holger recaps the topics decisions to date made regarding translating CPython
sources.  The Python language isn't to be modified, CPython takes lead 
wherever possible, and clean abstractions lead his list:

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


__builtin__, in Python
----------------------

Scott Fenton posts his replacement for the __builtin__ module:

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

The discussion turns to Scott's implementation of ord() and chr(), with
Armin pointing out that these would be supplied to the interpreter, 
not by it:

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

Scott later says that his implementation wasn't meant to be definitive:

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

Bengt Richter tries to factor out some of the differences between type
representation, and Scott and Samuele Pedroni discuss untyped bit vectors:

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


Ctypes News
-----------

Thomas Heller posts news about the Ctypes module, noting that argument
conversion was rewritten, and that libffi is integrated:

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


Python Bytecode from... GCC?
----------------------------

Thomas Fanslau asks generating Python bytecode from GCC would be possible, and
Nathan Heagy says it would be difficult:

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


Compiler Package Notes
----------------------

Logistix posts his notes on the compiler package.  Michael Hudson confirms 
most of his impressions:

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

Jeremy Hylton posts with his status on the package, and summarizes the work
left to be done:

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

Jeremy wonders if Minimal Python would need to generate CPython-compatible 
bytecode, and Christian thinks it may not:

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

Armin posts an interesting solution to Jeremy's stack-depth computation
problem.  His solution is the main interpreter loop of Python in Python:

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


Miasma: x86 machine Code Generation in Python
----------------------------------------------

Darius Bacon posts his x86 code generator, and Holger asks him 
to explain the challenges and solutions:

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


Object-Derived
--------------

Scott Fenton wonders how to implement classmethod, thinking it is only
applicable to subtypes of object.   Christian corrects the misunderstanding
and suggests coding for old and new-style classes:

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

Christian also proposes an extension to the new class system.  His extension
would have __slots__ indicate their type and allow types to derive from
nothing.


Builtin Types
-------------

Bengt Richter posts his ideas on "describing C structures in a canonical
abstract way".  Darius Bacon recognizes this as "First-Class Data-type
Representation in SchemeXerox".  Thomas Heller mentions these ideas are 
already present in ctypes:

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

Christian thinks of using Ctypes as the first target of a types implementation
in Python.  Samuele Pedroni brings up the issue of abstracting use of
PyTypeObject and the interpreter internal inheritance and lookup mechanisms:

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

The issue of using Ctypes as the basis of a type system in Python is debated.
Agreement is reached that the type system must describe types, but 
implementing the system is not urgent:

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

Holger posts his set of restrictions for the pypy-python-interpreter.  Armin
clarifies some of them and posts his additions:

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


__builtin__, Again
-------------------

Scott Fenton posts his updated version of __builtin__:

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

The working URL for Scott’s code comes a few messages later:

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

Holger thinks having this code pass the equivalent CPython tests would be
nice, and that scripting doc string generation would be easy:

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

Pedro Rodriguez adds his Python implementation of the dir() builtin:

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


Bits with Types
---------------

Bengt Richter posts initial ideas on a generic approach to evaluating machine
code:

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


Modeled from Smalltalk
----------------------

Stephan Diehl suggests looking at Smalltalk and how it has been implemented in
Smalltalk:

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


List Archive
------------

David Ascher sends a notice that ASPN is hosting an archive of the pypy-dev
list:

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



whew! 

-troy

More information about the Pypy-dev mailing list