|
| Current Newswire:
Python-dev summary, December 1-15, 2000Dec 21, 2000, 08:20 (0 Talkback[s])(Other stories by A.M. Kuchling) Date: Wed, 20 Dec 2000 21:14:24 -0500 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:
PyUnit:
http://pyunit.sourceforge.net
unittest.py from Quixote:
http://x63.deja.com/=usenet/getdoc.xp?AN=683946404 (intro)
http://www.amk.ca/python/unittest.html (docs)
doctest:
http://starbase.neosoft.com/~claird/comp.lang.python/doctest.html
David Goodger pointed out another unit testing implementation:
http://www.objectmentor.com/freeware/downloads.html
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'." __findattr__ 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__: 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": 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):
0 Talkback[s]
(click to add your comment)
|
