Python-dev summary, December 1-15, 2000

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:

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’.”

http://mail.python.org/pipermail/python-dev/2000-December/010882.html

__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.”
http://python.sourceforge.net/peps/pep-0231.html

__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.”

http://mail.python.org/pipermail/python-dev/2000-December/010913.html

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

http://mail.python.org/pipermail/python-dev/2000-December/011085.html

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:

http://mail.python.org/pipermail/python-dev/2000-December/010916.html

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.
http://python.sourceforge.net/peps/pep-0207.html

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:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102652&group_id=5470

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().
http://python.sourceforge.net/peps/pep-0217.html

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:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102864&group_id=5470

PEP 230, a warning framework proposal, also received GvR’s final
approval during this time period.
http://python.sourceforge.net/peps/pep-0230.html

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.
http://python.sourceforge.net/peps/pep-0232.html

http://python.sourceforge.net/peps/pep-0233.html

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

http://mail.python.org/pipermail/python-dev/2000-December/011051.html

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!”

http://mail.python.org/pipermail/python-dev/2000-December/011054.html

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:

http://mail.python.org/pipermail/python-dev/2000-December/010971.html

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

http://sourceforge.net/patch/?func=detailpatch&patch_id=102813&group_id=5470

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/