[LWN Logo]
[Timeline]
Date: Mon, 4 Dec 2000 22:00:03 -0500
From: "A.M. Kuchling" <akuchlin@mems-exchange.org>
To: python-announce@python.org
Subject: python-dev summary, Nov 16-30

Python-dev summary, November 16-30, 2000  
========================================

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 <URL:http://www.amk.ca/python/dev/>.

It was a quiet two weeks, with only 215 postings to python-dev.  Guido
was on vacation, which doubtless contributed to the silence.


Python standardization?
=======================

Mark Lutz worried about whether Python is changing too quickly.
"Things seem to be changing too fast for many developers to keep up,
and it seems to me that a formal standard doc might help ease a few
fears I've seen out there.  Books used to be a sort of de facto
standard, but even they aren't reliable anymore; and the manuals
aren't useful as a standard if they are open to arbitrary change every
few months."
        http://www.python.org/pipermail/python-dev/2000-November/027997.html

M.-A. Lemburg was dubious: "I don't see how a Python standard would do
any good. Standards have version numbers as well and change at about
the same rate (e.g. take Unicode 2.0 vs. Unicode 3.0)."
        http://www.python.org/pipermail/python-dev/2000-November/027998.html

Christian was more positive: "I don't see the danger of bureaucracy so
much. Instead, setting a standard is a sign of maturity for a language."
        http://www.python.org/pipermail/python-dev/2000-November/027999.html

It's doubtful Mark will gain much comfort from the discussion, because
most people viewed a standard as specifying degrees of flexibility
exploitable by alternative implementations of Python, which would only
lead to *more* variations, not fewer.


Other stuff
===========

In a boring echo of the .setdefault() method, some new dictionary
methods of minor usefulness were suggested, for looping through a
dictionary without actually constructing the full .keys() or .values()
list.  As Tim points out, these methods would be handy for
constructing an efficient set class: "This operation can't be done
efficiently in Python code if the set is represented by a dict (the
best you can do is materialize the full list of keys first, and pick
one of those).  That means my Set class often takes quadratic time for
what *should* be linear-time algorithms." 
        http://www.python.org/pipermail/python-dev/2000-November/028081.html

Jeffrey C. Ollie notified the python-dev list that, as an experiment,
he embedded Python in the Exim mail transport agent: "I imagine that
embedding Python in Exim will be interesting to those folks writing
virus scanners or for VERY tight integration of Mailman with Exim."  
There were no follow-ups.
        http://www.python.org/pipermail/python-dev/2000-November/028074.html

The .capitalize() method is inconsistent between Unicode and regular
strings, and the documentation is unclear about its definition.  Does
S.capitalize() return the string with its first character capitalized
and no other changes, or with the rest of the string lowercase?  Guido
ruled that the latter interpretation is the intended one.
        http://www.python.org/pipermail/python-dev/2000-November/028130.html

AMK submitted PEP 229, aiming to use the Distutils to build and
install Python's standard library in place of the current
Modules/Makefile.pre.in and makesetup mechanism.
        http://python.sourceforge.net/peps/pep-0229.html


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/