Python-dev summary, December 16-31, 2000
Jan 01, 2001, 00:51 (0 Talkback[s])
(Other stories by A.M. Kuchling)
Re-Imagining Linux Platforms to Meet the Needs of Cloud Service Providers
Date: Sun, 31 Dec 2000 15:19:02 -0500
From: A.M. Kuchling email@example.com
Subject: python-dev summary, Dec. 16-31
I'm a bit early this time, betting that no new topic of great
interest will arise in the next 9 hours.
Python-dev summary, December 16-31, 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 http://www.amk.ca/python/dev/.
The past two weeks turned out to be less quiet than expected,
though most of the items discussed were minor.
2.1 release plans
December 15 was the deadline for PEPs; no new PEPs will be
considered for inclusion in 2.1, and PEPs not in the active list
will not be considered either. Martin von Loewis wondered if the
timetable for Python 2.1 was realistic: "I think it is unrealistic
to expect the same amount of commitment for the next release,
especially if that release appears just a few months after the
previous release (that is, one month from now)."
GvR thought that the ideas being considered for Python 2.1 were
much smaller than the changes that went into 2.0, and listed them:
Eric S. Raymond noted that the curses module isn't automatically
built, and that in general more modules could be built without
requiring explicit user intervention: "This is not good, as it may
lead careless distribution builders to ship Python 2.0s that will
not be able to support the curses front end in CML2."
AMK has been working on PEP 229, a proposal to automatically
configure and compile extension modules, and the accompanying
patch. This would replace the Module/Setup file and makesetup
script, and fix ESR's problem.
On that note, a link was posted to the current version of the
automatic setup.py script, asking for people to try it out on
various platforms and offer corrections: "Is anything missing that
should have been built? Did an attempt at building a module fail?
These indicate problems autodetecting something, so if you can
figure out how to find the required library or include file, let me
know what to do." Instructions are in my post:
The setup script can be downloaded from:
Please give it a try.
People have suggested adding a chomp() function that performs
the same task as the Perl built-in: it removes the trailing newline
from a string.
Reaction was mixed: Moshe liked it, but others thought that the
existing rstrip() method, which removes *all* whitespace from the
end of a string, is sufficient.
Calls for assistance
Moshe Zadka noted that the FAQ is out of date, and that the
FAQwizard on python.org had been down for some time without anyone
noticing: "I think the FAQ-Wizard method has proven itself not very
efficient (for example, apparently no one noticed until now that
it's not working)." The FAQ should really be maintained by an
editor; does anyone want to volunteer?
The PSA bookstore has been updated, rewritten, and resurrected
as the Python bookstore. Contributions of additional reviews,
suggestions for titles, etc. are welcome.
The mailing lists on python.org ran into trouble near the end of
the month; list services were moved from a machine at CNRI to one
at Digital Creations, the disk on mail.python.org filled up,
Postfix on mail.python.org inserts a delay of some hours, and a bug
in Mailman was found: "This is serious enough to warrant a Mailman
2.0.1 release, probably mid-next week."
The changes to the curses module to export a C API, discussed in
the previous python-dev summary, met with approval and were checked
in. This meant that Thomas Gellekum's curses.panel module could
also be added. Anyone want to work on wrapping the form and/or menu
libraries that come with ncurses?
Python may avoid the need to argue over where to put the braces,
but there's still the need to use a consistent style in Python's C
code. Fred Drake suggested using 4-space indents, no tabs; this is
different from GvR's preferred style, but according to Fred, the
4-space style is tolerated as an alternative. GvR pronounced on
this: "If 3rd party code is already written using a different
style, it can stay that way, especially if it's a large volume that
would be hard to reformat."
Python project page on SourceForge:
Python Enhancement Proposals (PEPs):