Python-dev summary, November 1-15, 2000
Nov 16, 2000, 09:37 (0 Talkback[s])
(Other stories by A.M. Kuchlin)
Re-Imagining Linux Platforms to Meet the Needs of Cloud Service Providers
Date: Wed, 15 Nov 2000 22:55:12 -0500
From: A.M. Kuchling
Subject: python-dev summary, Nov 1-15
Python-dev summary, November 1-15, 2000
To comment on material in this python-dev summary, you can
simply post to comp.lang.python / firstname.lastname@example.org. These
summaries are archived at .
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
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
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):