Date: Wed, 7 Feb 2001 22:35:22 -0500
From: A.M. Kuchling akuchlin@mems-exchange.org
To: python-announce@python.org
Subject: python-dev summary, Jan. 16-31
Python-dev summary, January 16-31, 2001
To comment on material in this python-dev summary, you can simply
post to comp.lang.python / . These summaries are archived at
http://www.amk.ca/python/dev/.
This two week period saw the release of the first alpha of
Python 2.1, and the second alpha was released a few days into
February. There’s a lot of bugfixing going on, much of which isn’t
of interest here, but there were a few general discussions worth
noting.
2.1alpha1
The first alpha of Python 2.1 was released on January 22, and is
the debut of Python 2.1. It didn’t compile cleanly on Cygwin, and
the new autodetecting build system needs some more work to support
more platforms correctly, but no major problems or brown paper bag
bugs showed up.
2.1alpha2 was subsequently released on February 2, slightly out
of the bounds of this summary. 2.1a2 incorporated the nested scopes
from PEP 227 and the weak reference type from PEP 205.
A draft of “What’s New in Python 2.1” is available, and will be
continuously updated until 2.1final is shipped:
http://www.amk.ca/python/2.1/
unistr()
M.-A. Lemburg checked in a unistr() built-in, but later backed out
the change after subsequent discussion. str() takes any Python
object and converts it to a string, and unistr() would take any
object and return a Unicode string. ?!ng wondered why the existing
unicode() built-in shouldn’t do this — currently it only accepts a
string and an optional encoding — or should this functionality be
added to str()?
This also raised the question of how a type could return a
Unicode representation of itself. Should the tp_str slot in the
Py_TypeObject struct be permitted to return either an 8-bit or a
Unicode string, or should a tp_unicode slot be added? Some
discussion followed, but no clear answer was apparent, so unistr()
was removed. This issue will probably have to wait for a PEP to be
written, which means that it’ll have to wait until 2.2.
Sets
Eric S. Raymond posted the docs for a set module he’s written with
an eye toward getting it into the standard library. “The
module{set} module defines functions for treating lists and other
sequences as mathematical sets, and defines a set class that uses
these operations natively and overloads Python’s standard operator
set.”
http://mail.python.org/pipermail/python-dev/2001-January/012005.html
But there’s already a PEP for a set type, #218 by Greg
Wilson:
http://python.sourceforge.net/peps/pep-0218.html
Reconciling the two proposals doesn’t seem difficult, but
opinion was divided: are sets so commonly used that they should be
in the standard library, particularly if dictionaries can be used
to implement many common set operations?
?!ng pointed out that simply allowing “if key in dict” would
make using dictionaries as sets a bit more natural. /F agreed, and
GvR added “You know, I’ve long resisted this, but I agree now —
this is the right thing.” Thomas Wouters submitted a patch, but it
hasn’t yet been checked in.
A subthread wondered about the related question of ‘for X in
dictionary:’ Should this do anything, and if so, what? X could be
“key” or “key, value”, but the best choice isn’t obvious. Another
subthread drifted into the question of the Batteries Included
distribution proposed by Moshe Zadka in PEP 206, and yet another
one proposed dictionaries that can be marked as unmodified
(“frozen” or
“locked”). No clear conclusions were made, and the problems seem
messy enough that a PEP will be required, so this is another thing
likely to be postponed until 2.2.
Envoi
This will be the last python-dev summary I write, accounting for
its rushed and sketchy quality.
The goal of these summaries has been to make the discussions on
python-dev more visible to the community, letting people offer
timely comments while a thread is still reasonably current and
fresh in memory. Unfortunately that doesn’t seem to happen, and no
messages to python-dev are spurred by them. Ideally people would
come forward to say “The last summary mentioned you were talking
about X. I use X a lot, and here’s what I think: …”, but that
isn’t happening.
The release of 2.1 offers a second calibration on their
effectiveness. 2.1 is the first Python release to have been carried
out using PEPs as the mechanism, so there are no sizable changes in
2.1 that don’t have a corresponding PEP. Yet many people were
*surprised* by some of the changes in Python 2.1 such as function
attributes and nested scopes, even though PEPs were written and
discussed, often in lengthy threads months ago.
To me, this makes it crystal clear that the summaries aren’t
achieving their goal of making the development process more
transparent to the community. Perhaps giving the PEPs higher
visibility — posting announcements of status changes and new PEPs
to comp.lang.python.announce, for example — would do a better job,
and it would definitely require less effort. In any case, I feel
there’s no point in continuing to write them.
(Should anyone want to volunteer to continue writing them,
please do so; contact me if you want copies of the previous
summaries for a complete archive.)
My thanks to the various people who’ve offered comments and
encouragement along the way; you’ve all kept me going over the last
7 months…
Related Links
Python-dev archives:
http://www.python.org/pipermail/python-dev/
Python project page on SourceForge:
http://sourceforge.net/projects/python
Python Enhancement Proposals (PEPs):
http://python.sourceforge.net/peps/
What’s New in Python 2.1
http://www.amk.ca/python/2.1/