To comment on material in this python-dev summary, you can
simply post to comp.lang.python / python-list@python.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
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!"
http://www.python.org/pipermail/python-dev/2000-November/017072.html

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.

Integer division

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."http://python.sourceforge.net/peps/pep-0228.html

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:
http://www.python.org/pipermail/python-dev/2000-November/017216.html

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
functions' namespaces."http://python.sourceforge.net/peps/pep-0227.html

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.

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.http://python.sourceforge.net/peps/pep-0222.html