Python-dev summary, November 1-15, 2000Nov 16, 2000, 09:37 (0 Talkback[s])
(Other stories by A.M. Kuchlin)
Date: Wed, 15 Nov 2000 22:55:12 -0500
Python-dev summary, November 1-15, 2000
The move to Digital Creations has broken the dam, burying python-dev in a flood of new ideas. This two week period was very busy, beginning with a call for feature proposals for Python 2.1.
This summary will therefore be more telegraphic than usual; it would be too time-consuming to summarize the major threads, which were all quite lengthy, and the final result would still distort the arguments. So, if one of the topics is of interest to you, please refer to the python-dev archives for all the details.
Python 2.1 tasks
GvR listed the PEPs he wants to consider for Python 2.1, and
requested more input: "If you have an idea for a PEP that you think
should be implemented in Python 2.1, or if you want to revive a PEP
that's currently listed in one of the "unattainable" categories,
now's the time to make a plea!"
Various people followed up stating what they'd like to work on: Moshe Zadka wants to tackle the question of integer division (see below), AMK wants to use the Distutils to build Python itself, and so forth.
Discussion of most of the topics covered in this summary was triggered by this call for suggestions. After being closely focused on the release of Python 2.0 for so long, python-dev is beginning to direct its gaze toward the distant horizon of the future.
Moshe drafted PEP 228, "Reworking Python's Numeric Model". This
PEP proposes a numeric model for Python that isn't based on C's
model, which ultimately derives from machine representations of
integers and floats. "While coercion rules will remain for add-on
types and classes, the built in type system will have exactly one
Python type -- a number."
The ensuing discussion was scattered, mostly revolving around whether and when to use rational numbers, and whether floating point literals should be considered exact or inexact numbers. It's not obvious that this PEP can be solidified in time for its results to be incorporated in Python 2.1.
Stackless Python, and microthreads
Some sort of resolution to Stackless Python seems likely for
2.1. Guido is inclined to take a solution for 90% of the problems:
"I still think that the current Stackless implementation is too
complex, and that continuations aren't worth the insanity they seem
to require (or cause :-), but that microthreads and coroutines
*are* worth having and that something not completely unlike
Stackless will be one day the way to get there..." He then went on
to post a strawman API for microthreads:
Christian Tismer agreed with him that continuations aren't
really necessary. "I'm happy to toss continuations for core Python,
if we can find the right building blocks for coro/gen/uthreads. I
think Guido comes quite near this, already."
And so did Tim: "I don't know of any comprehensible application
of continuations that can't be done without them."
Christian Tismer enumerated the changes to ceval.c made by
Finally, Gordon McMillan put up a Stackless intro and
The seam that runs between classes, defined in Python code, and types, defined in C code, has been in Python from the beginning. Various schemes for bridging the gap were suggested.
M.A. Lemburg suggested adding an extra indirection, letting C
types identify themselves as subclasses of another C type:
Greg Ewing, inspired by Ruby's implementation, suggested adding
a global dictionary to add extra attributes to type instances:
Python's two-level scoping rules have been the subject of debate for a while. Many new users expect Python to have Pascal-like static scoping and are surprised when variable references in lambdas or other nested functions behave unexpectedly. Previously this would have presented technical problems, since nesting scopes would create cyclical references, which couldn't be handled by Python's reference counting.
Jeremy wrote PEP 227, "Statically Nested Scopes", to make a
concrete proposal: "The current language definition defines exactly
three namespaces that are used to resolve names -- the local,
global, and built-in namespaces. The addition of nested scopes
would allow resolution of unbound local names in enclosing
Some discussion ensued, mostly about whether it's worth changing this just to fix nested functions. A side thread on dynamic scoping, as opposed to static, spun off at one point, but since practically everyone thought it was a bad idea, nothing emerged from it worth summarizing.
Another item on GvR's list for 2.1 was a framework for printing
Coincidentally, Paul Prescod was also working on a warning
framework, and had a draft PEP:
AMK tried to raise some interest in PEP 222, which lists some
improvements to make Web programming in Python easier, but there
seems to be little interest. If no further interest is shown by the
community, the PEP will simply be abandoned.
A Web page listing critical patches for 2.0 was created:
Python project page on SourceForge:
Python Enhancement Proposals (PEPs):
0 Talkback[s] (click to add your comment)