Linux Today: Linux News On Internet Time.

Python-dev summary, December 16-31, 2000

Jan 01, 2001, 00:51 (0 Talkback[s])
(Other stories by A.M. Kuchling)

Date: Sun, 31 Dec 2000 15:19:02 -0500
From: A.M. Kuchling akuchlin@mems-exchange.org
To: python-announce@python.org
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 / python-list@python.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: http://mail.python.org/pipermail/python-dev/2000-December/011069.html

Module autoconfiguration

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." http://mail.python.org/pipermail/python-dev/2000-December/011194.html

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.

The patch:

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:
http://mail.python.org/pipermail/python-dev/2000-December/011231.html The setup script can be downloaded from:
http://www.amk.ca/files/python/setup.py 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.

Other stuff

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."

Related Links

Python-dev archives:

Python project page on SourceForge:

Python Enhancement Proposals (PEPs):