Linux Today: Linux News On Internet Time.

More on LinuxToday

Python-dev summary, December 1-15, 2000

Dec 21, 2000, 08:20 (0 Talkback[s])
(Other stories by A.M. Kuchling)


How to Help Your Business Become an AI Early Adopter

Date: Wed, 20 Dec 2000 21:14:24 -0500
From: A.M. Kuchling amk@mira.erols.com
To: python-announce@python.org
Subject: python-dev summary, Dec. 1-15

Python-dev summary, December 1-15, 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

A busy two weeks, particularly for the PEPs, where there were several major edits and changes of status. The deadline for PEPs for Python 2.1 is Dec. 15; after this point, no new PEPs will be added to the list (though they may be taken off the list if implementation turns out to be impractical or the proposed idea proves a bad one).

I expect the next two week period to be slow on python-dev, since most people will be off on vacation, celebrating the holiday, or otherwise distracted.

Unit testing

Jeremy Hylton wondered about adding a unit testing framework to Python. The list of suggested candidates produced by people on python-dev is:

unittest.py from Quixote:
        http://x63.deja.com/=usenet/getdoc.xp?AN=683946404 (intro) 
        http://www.amk.ca/python/unittest.html (docs) 
David Goodger pointed out another unit testing implementation:
If readers of this summary know of other unit testing tools for Python, please let python-dev know about them.

Peter Funk compared doctest and Quixote's unittest.py: "After reading Andrew's docs, I think Quixote basically offers three additional features if compared with Tim Peters 'doctest'."


Barry Warsaw submitted PEP 231, suggesting a new __findattr__() hook. "My hope is that __findattr__() would eliminate most, if not all, the need for ExtensionClass, at least within the Zope and ZODB contexts. I haven't tried to implement Persistent using it though."

__findattr__ would be called on every attribute access, unlike __getattr__ which is only called when the attribute is not found in an instance's dictionary. The recursive from __findattr__ was a problem, though; how would the __findattr__ access any of the contents of an instance, since it would be recursively called on any attribute access within the body of the __findattr__()? Barry's PEP used a .infindattr attribute that would be set to true inside a __findattr__ method, but that isn't thread-safe. Other approaches were suggested -- store this in the thread state, compile special tricks into the bytecode compiled for __findattr__ calls.

GvR's response to all this was "I'm unconvinced by the __findattr__ proposal as it now stands," and went on to reject the PEP.

Iterating through dictionaries

Discussion about iterating through dictionaries without constructing a list of keys (the .popitem() proposed in the 2 weeks covered by the previous python-dev summary). Christian Tismer analyzed the math for the hash tables that underly dictionaries: "The powers of µ reach all these patterns. Therefore, each pattern *is* some power of µ. By multiplication with µ we can reach every possible pattern exactly once. Since these patterns are used as distances from the primary hash-computed slot modulo 2^n, and the distances are never zero, all slots can be reached."

Christian went on to use this to attempt to improve the hashing algorithm used for dictionaries: "While the current algorithm is 110 times slower on a worst case dict (quadratic behavior), the new algorithm accounts a little for the extra cycle, but is only 4 times slower."

Tim thought that the GF() hashing wasn't relevant to the problem of consuming the entire contents of a dictionary, and proposed a different popitem() implementation:

PEP Progress

PEP 207, the Rich Comparison PEP, was updated by Guido. Rich comparisons would provide more flexibility, making it possible to separately overload <, >, <=, >=, ==, != in classes, and to return something besides a Boolean result. The idea has been around for years, and David Ascher wrote an earlier proposal a few years ago. PEP 207 is mostly a re-editing of David's proposal by GvR.

Neil Schemenauer has been beavering away at PEP 208, clarifying the semantics and the implementation of __coerce__:
http://python.sourceforge.net/peps/pep-0208.html The patch for Neil's reference implementation is patch #102652:

GvR approved PEP 217, written by Moshe Zadka: "Display Hook for Interactive Use". This PEP adds a sys.displayhook(obj) function which is called to display results in the interactive interpreter, making it easy to use str() or a fancy pretty-printing function instead of just the default repr().

Jeremy Hylton updated PEP 227, "Statically Nested Scopes":
http://python.sourceforge.net/peps/pep-0227.html Jeremy's prototype implementation is available as patch #102864:

PEP 230, a warning framework proposal, also received GvR's final approval during this time period.

Three new PEPS: #231 was born and died during this time period, and is discussed in the __findattr__ section above. #232 is Barry Warsaw's proposal for function attributes, and 233 is Paul Prescod's proposal for an on-line help facility in the interpreter.

Deprecating the string module?

GvR made a few checkins that replaced uses of string.* functions with string methods. Neil Schemenauer asked "Can you explain the logic behind this recent interest in removing string functions from the standard library? It it performance? Some unicode issue?"

Guido's response was "As a realistic test of the warnings module I played with some warnings about the string module, and then found that most of the std library modules use it, triggering an extraordinary amount of warnings."

Tim wondered if this was really necessary: "'string' is right up there with 'os' and 'sys' as a FIM (Frequently Imported Module), so the required code changes will be massive. As a user, I don't see what's in it for me to endure that pain: the string module functions work fine!"

This sparked a lengthy debate; *is* the string module going away? Guido dislikes the duplication in having both a string module and string methods, though it would only disappear several major releases in the future; Barry Warsaw prefers string methods over string functions. While Greg Wilson also liked removing the duplication of functionality, GvR and Barry seem to be otherwise alone on this point; no one sees the need to remove the string module, and some people don't like string methods that much, particularly in certain cases such as the .join() method.

Other stuff

Thomas Gellekum submitted a wrapper for the panel library that comes with ncurses. However, the additional code would make _cursesmodule.c even larger (60K, 2500 lines), so instead AMK proposed splitting up the C module. Fred Drake pointed out a better way, using CObjects to export an API:

A patch was submitted to SourceForge, and is currently waiting for more people to look at it:

Related Links

Python-dev archives:

Python project page on SourceForge:

Python Enhancement Proposals (PEPs):

We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.