[Python-Dev] DRAFT: python-dev summary for 2006-04-16 to 2006-04-30

Steven Bethard steven.bethard at gmail.com
Tue Jun 13 07:45:48 CEST 2006

Ok, here's the summary for the second half of April.  My brain is numb
from the setuptools ane PEP 343 discussions, so please have a look
over it and see what I messed up. ;-)

As always, if you have any corrections or comments, please let me know.


Python 2.5 alpha 2 released

Python 2.5 alpha 2 was released on April 27th.  If you haven't tried
it out yet, now's the time!  `PEP 356`_ has more details and the full

.. _PEP 356: http://www.python.org/dev/peps/pep-0356/

Contributing threads:

- `TRUNK FREEZE from 00:00 UTC, 27th April 2006 for 2.5a2
- `RELEASED Python 2.5 (alpha 2)
- `trunk is UNFROZEN
- `2.5 open issues

QOTF: Quote of the Fortnight

Phillip J. Eby, on the social behavior of package distributors (and
why setuptools goes to such efforts to guess what package distributors
were really trying to do):

    The problem isn't fundamentally a technical one, but a social one.
 You can effect social change through technology, but not by being
some random guy with a nagging 'bot.

(And yes, Phillip, you can nominate yourself for QOTF.) ;-)

Contributing thread:

- `setuptools: past, present, future


Adding setuptools to the stdlib

Phillip J. Eby started checking in some of the `setuptools`_ modules
for Python 2.5.  People started to get nervous about some of the
modules because:

* Setuptools changes the distutils "install" command to install
everything as zipfile eggs
* Setuptools changes the distutils "sdist" command to automate
generation of MANIFEST.in and MANIFEST.
* Setuptools adds 'site.py' files so that .pth files are processed in
PYTHONPATH directories.
* Setuptools monkey-patches three classes from distutils:
Distribution, Command, and Extension.

While most people recognized the need for the features that setuptools
provides, a number of them objected to introducing setuptools as a new
package and instead argued for merging setuptools into distutils.
Phillip said that such a merge might be possible, but that there were
a fair number of backwards compatibility concerns (e.g. its
redefinition of the "install" and "sdist" commands) and that it would
make it much harder for him to maintain external versions of
setuptools compatible with Python 2.3 and 2.4.

In the end, Phillip suggested withdrawing setuptools from Python 2.5,
and figuring out how to merge setuptools into distutils for the 2.6
release.  In particular, he asked for help with the mostly trivial
porting of the "alias", "rotate", "saveopts" and "setopt" commands.
Additionally, he made available some information about the `setuptools
internals`_ for anyone who wanted to see better what was going on
behind the scenes.

.. _setuptools: http://peak.telecommunity.com/DevCenter/setuptools
.. _setuptools internals: http://peak.telecommunity.com/DevCenter/EggFormats

Contributing threads:

- `[Python-checkins] r45510 - python/trunk/Lib/pkgutil.py
- `Place for setuptools manuals and source for .exe files?
- `setuptools in the stdlib ([Python-checkins] r45510 -
python/trunk/Lib/pkgutil.py python/trunk/Lib/pydoc.py)
- `setuptools in the stdlib ( r45510 - python/trunk/Lib/pkgutil.py
- `setuptools in the stdlib
- `Raising objections (was: setuptools in the stdlib)
- `Raising objections
- `3rd party extensions hot-fixing the stdlib (setuptools in the
stdlib) <http://mail.python.org/pipermail/python-dev/2006-April/063930.html>`__
- `setuptools in 2.5.
- `magic in setuptools (Was: setuptools in the stdlib)
- `Distutils for Python 2.1 (was "Raising objections")
- `setuptools in 2.5. (summary)
- `Distutils thoughts
- `setuptools: past, present, future
- `Easy, uncontroversial setuptools->distutils tasks
- `Internal documentation for egg formats now available

PEP 343: The "with" Statement

A.M. Kuchling asked about some terminology in the `PEP 343`_
documentation.  Originally, the objects with ``__enter__`` and
``__exit__`` methods which were used in the with-statement were called
"context managers".  When the additional ``__context__`` method was
introduced, the term "manageable context" was given to objects that
provided it.  At PyCon, the PEP was changed to switch the terms,
though the names of ``decimal.Context`` and
``contextlib.contextmanager`` were not changed correspondingly.  This
all led to a rather confusing discussion where people argued over the
terminology, appropriately summarized in this quote by Phillip J. Eby:

    ...everybody has been perfectly clear, we just haven't really
gotten on the same page about which words mean what.

People then played around with a variety of alternative terms
("context factory", "context specifier", etc.) but in the end, Guido
decided that it was much clearer to just drop the ``__context__``
method entirely -- most use-cases at the time just had ``__context__``
returning self, and the few use-cases that didn't could be accomodated
with an appropriately named method or function.  And dropping the
``__context__`` method meant that only the term "context manager" was
necessary, removing most of the earlier terminological confusion.

.. _PEP 343: http://www.python.org/dev/peps/pep-0343/

Contributing threads:

- `PEP 343: confusing context terminology
- `Why are contexts also managers? (was r45544 -
- `With context, please
- `PEP 343 update (with statement context terminology)
- `Must objects with __enter__/__exit__ also supply __context__?
- `Updated context management documentation
- `[Python-checkins] r45721 - python/trunk/Lib/test/test_with.py
- `More on contextlib - adding back a contextmanager decorator

Dropping __init__.py requirement for subpackages

After some pressure from other Googlers, Guido suggested that Python
drop the requirement that subpackages have an __init__.py file (though
top-level packages would still require one).  People were concerned
that a number of non-subpackage directories would suddenly become
packages, e.g. "test" in the Python distribution.  There was also some
concern about tools that depended on the current requirement -- any
tool that currently searches directories for __init__.py files would
have to be updated to work with the new semantics.  In the end,
`Thomas Wouters provided a patch`_ that makes Python now issue a
warning when it would have imported a module but failed to because
__init__.py was missing.

.. _Thomas Wouters provided a patch: http://bugs.python.org/1477281

Contributing threads:

- `Dropping __init__.py requirement for subpackages
- `[Python-checkins] r45770 - in python/trunk:

Python and Visual Studio 2005 Express

Guido noticed that Microsoft had announced that `Visual Studio 2005
express will be free forever`_, and asked if Python should try to
accomodate this.  People seemed to think that switching to Visual
Studio 2005 for Python 2.5 was too soon but that 2.6 might be a
reasonable candidate, particularly since Microsoft no longer provides
downloads for the Visual Studio 2003 compiler.

.. _Visual Studio 2005 express will be free forever:

Contributing thread:

- `Visual studio 2005 express now free

Adding wsgiref to the stdlib

Guido suggested adding Phillip J. Eby's `reference implementation`_ of
`PEP 333`_ (the Web Server Gateway Interface) to the standard library.
 People were generally in favor, though there was some brief
discussion about adding a few extras including Ian Bicking's
paste.lint validator and a simple dispatch mechanism.  It looked like
wsgiref would be added in time for Python 2.5.

.. _reference implementation: http://svn.eby-sarna.com/wsgiref/
.. _PEP 333: http://www.python.org/dev/peps/pep-0333/

Contributing threads:

- `Adding wsgiref
- `Adding wsgiref to stdlib
- `[Web-SIG] Adding wsgiref to stdlib

Buildbots on Windows

Some of the Windows buildbots were hanging when the buildbot slave
terminated the run early, but failed to terminate python_d.exe, thus
making it impossible to recompile anything (since python_d.exe cannot
be deleted while running on Windows).  No one was certain what was
causing the problems (though it seemed like it might be some sort of
indexing service running in the background) but Martin v. Löwis was
able to unstick the machines by creating a kill_python.exe application
which looks for python_d.exe and kills it.

Contributing thread:

- `windows buildbot failures

Externally maintained packages PEP

Following up on work from the last fortnight, Brett Cannon put
together information on all the packages like sqlite and elementtree
that are part of the Python standard library, but have their central
repository somewhere else.  It looked like a PEP would soon be

Contributing threads:

- `need info for externally maintained modules PEP
- `draft of externally maintained packages PEP
- `(hopefully) final draft of externally maintained code PEP

PEP 359: The "make" statement

Discussion continued on `PEP 359`_'s "make" statement continued,
looking in particular at ways that breaking the parallel with the
class statement might make the "make" statement easier to use.  In the
end Guido asked me to kill the discussion, so I withdrew the PEP.

.. _PEP 359: http://www.python.org/dev/peps/pep-0359/

Contributing threads:

- `PEP 359: The "make" Statement
- `Updated: PEP 359: The make statement

PEP 3102: Keyword-only arguments

Talin introduced `PEP 3102`_ which proposes support for "keyword-only"
arguments, that is, arguments that must be specified with the
name=value keyword syntax, not as positional arguments.  The proposal
came in two parts:

* Allowing keyword arguments after varargs, e.g.::

      def add_option(*opts, action='store', type='string', ...)

* Allowing keyword arguments with no varargs, e.g.::

      def compare(a, b, *, key=None):

There was widespread support for the first part of the PEP,
particularly since such signatures exist in functions like the builtin
min and max already (which gained key= arguments in Python 2.5).  The
latter part people were unsure of, and suggested a variety of other
syntaxes, though Guido had already decided on the "*" syntax.
Discussion continued on this issue into the next fortnight.

.. _PEP 3102: http://www.python.org/dev/peps/pep-3102/

Contributing thread:

- `PEP 3102: Keyword-only arguments

String formatting for size_t objects

Brett Cannon ran into some problems with the formatting of size_t
objects.  What was really needed was the C99 "z" printf modifier, but
since Python aims for C89 conformance, that can't be used
unconditionally.  In the end, Brett Cannon modified Python's config to
test if the "z" modifier is supported and then used that whenever

Contributing threads:

- `PY_FORMAT_SIZE_T warnings on OS X
- `PY_FORMAT_SIZE_T warnings on OS X

The Grammar file and SyntaxErrors

In working on a parser for a subset of the Python language, Michael
Foord ran into some troubles using the Grammar/Grammar file in the
Python distribution.  In particular, the problem he was having was the

    list_for: 'for' exprlist 'in' testlist_safe [list_iter]

which indicates that any expression list can be used as the assignment
expression in a list comprehension, so that code like the following is
valid by the Grammar file::

    [1 for 1 in n]

Of course Python doesn't allow this, but as Guido explained, the
expression that Python really wants is not LL1, so Python fudges it in
the parser, and then issues a SyntaxError later by checking that the
nodes in the parse tree actually match the restricted type of nodes

Contributing thread:

- `Python Grammar Ambiguity

Pybench now in Python SVN

Marc-Andre Lemburg offered to contribute pybench to Python in response
to a previous thread indicating some of the problems with pystone.
It's now checked in under the Tools directory.

Contributing thread:

- `2.5a1 Performance

Adding threading.released()

Nick Coghlan asked if the ``released()`` function suggested in `PEP
343`_ should be added for Python 2.5 to support code like::

    def thread_safe():
        with sync_lock:
            # This is thread-safe
            with released(sync_lock):
                # Perform long-running or blocking operation
                # that doesn't need to hold the lock
            # We have the lock back here

While it seemed occasionally useful (e.g. in the implementation of
threading._Condition), this one looked like it would be put off until
folks had had more experience with context managers.

Contributing thread:

- `Proposed addition to threading module - released

Removing the me_hash for dicts

Kirat Singh asked about removing me_hash from the dict struct to save
some space.  People generally seemed opposed to trading off speed for
space, particularly since it would slow down classes that define their
own ``__hash__``.

Contributing thread:

- `Reducing memory overhead for dictionaries by removing me_hash

PEP 3101: Advanced String Formatting

Talin introduced `PEP 3101`_ which proposes a new formatting system
through a new ``string.format()`` method.  This would allow specifying
items through both positional and keyword arguments, as well as
allowing user-defined classes to support their own set of format
specifiers, e.g.::

    "The story of {0}, {1}, and {c}".format(a, b, c=d)
    "Today is: {0:%x}".format(datetime.now())

There was some brief discussion about how to escape the brace
characters, and some opposition to the compound name syntax (which
allowed __getitem__-style access using a dotted notation) before the
thread trailed off.

.. _PEP 3101: http://www.python.org/dev/peps/pep-3101/

Contributing thread:

- `PEP 3101: Advanced String Formatting

Replacing SourceForge

Brett Cannon asked for some things that people liked and disliked
about SourceForge as the Infrastructure committee moved forward on
finding a replacement tracker for SF.  There weren't too many positive
comments, but some of the things SF was missing are:

* A way to flag a patch as "reviewed"; "pending" won't work -- it just
sets a timeout period and then deletes the message.
* A way to tag a tracker item by the relevant documentation section
(e.g. language reference, library reference, etc.)
* The ability to participate in a bug discussion through email instead
of the web interface
* The ability to define a filter on tracker items so that you can be
emailed when a new tracker item meets your criteria
* A way to identify relations between bugs, e.g. this bug closes another bug.
* The ability to close a bug with a checkin.

A Call for Trackers was to be soon forthcoming.

Contributing threads:

- `Reviewed patches [was: SoC proposal: "fix some old, old bugs in
sourceforge"] <http://mail.python.org/pipermail/python-dev/2006-April/064342.html>`__
- `what do you like about other trackers and what do you hate about
SF? <http://mail.python.org/pipermail/python-dev/2006-April/064343.html>`__
- `Reviewed patches

Making decorated functions easier to introspect

Nick Coghlan offered to add a function to the new functools module to
make writing introspectable decorators easier.  Many decorators that
return new functions look something like::

    def decorator(func):
        def new_func(*args, **kwargs):
        return new_func

But the newly created function metadata (__name__, __doc__, etc.) is
now inconsistent with the original function.  Originally, Nick had
proposed introducing a decorator function to do this, but he settled
instead on a simple helper function, ``functools.update_wrapper``,
which can be called by decorator writers to update the appropriate

Contributing thread:

- `Adding functools.decorator

Tkinter hangs due to Tk bug

Thomas Wouters noticed that test_tcl locked up when Tcl and Tk were
compiled with --enable-threads and he tried to refleaktest Tkinter.
Seems that despite the lack of any note in the Tk documentation,
Tk_Init() doesn't like being called twice even when the first call
results in an error.  Martin v. Löwis reported the bug to the Tk folks
and added a workaround for the current behavior.

Contributing thread:

- `Tkinter lockups.

Deferred Threads
- `binary trees. Review obmalloc.c
- `introducing the experimental pyref wiki
- `methods on the bytes object

Previous Summaries
- `[Python-checkins] r45321 - in python/trunk:
Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
- `Py_Finalize does not release all memory, not even closely
- `Preserving the blamelist
- `PyObject_REPR()
- `New-style icons, .desktop file
- `Win64 AMD64 (aka x64) binaries available64

Skipped Threads
- `valgrind reports
- `Any reason that any()/all() do not take apredicateargument?
- `refleaks &amp; test_tcl &amp; threads
- `2.5 post-alpha1 broken on mac-intel machines
- `Summer of Code preparation
- `[C++-sig] GCC version compatibility
- `remote debugging with pdb
- `Py_BEGIN_ALLOW_THREADS around readdir()?
- `FYI: more clues re: tee+generator leak
- `[ python-Patches-790710 ] breakpoint command lists in pdb
- `FishEye on Python CVS Repository
- `problem installing current cvs - TabError
- `fat binaries for OSX
- `Returning -1 from function with unsigned long type
- `adding Construct to the standard library?
- `posix_confstr seems wrong
- `pdb segfaults in 2.5 trunk?
- `possible fix for recursive __call__ segfault
- `How to make _sre.c compile w/ C++?
- `Gentoo failures - it's blaming me...
- `a flattening operator?
- `[Python-checkins] r45505 - python/trunk/Modules/posixmodule.c
- `bug with __dict__?
- `Python Software Foundation seeks mentors and students for Google
Summer of Code <http://mail.python.org/pipermail/python-dev/2006-April/063965.html>`__
- `PEP 355 (object-oriented paths)
- `proposal: evaluated string
- `SVN question
- `Google Summer of Code proposal: Pdb improvments
- `Stream codecs and _multibytecodec
- `python 2.5alpha and naming schemes
- `unrecognized command line option "-Wno-long-double"
- `extended bitwise operations
- `Weekly Python Patch/Bug Summary
- `[pypy-dev] Python Software Foundation seeks mentors and students
for Google Summer of Code
- `Google Summer of Code proposal: improvement of long int and adding
new types/modules.
- `bin codec + EOF
- `Module names in Python: was Re: python 2.5alpha and naming schemes
- `Removing Python 2.4 -m switch helpers from import.c
- `patch #1454481 - runtime tunable thread stack size
- `[Python-3000-checkins] r45617 - in
CodeWarrior/CodeWarrior_suite.py CodeWarrior/__init__.py
Explorer/__init__.py Finder/Containers_and_folders.py Finder/Files.py
Finder/Finder_Basics.py Finder
- `[Python-3000-checkins] r45617 - in
CodeWarrior/CodeWarrior_suite.py CodeWarrior/__init__.py
Explorer/__init__.py Finder/Containers_and_folders.py Finder/Files.py
- `Reject or update PEP 243?
- `IronPython Performance
- `[pypy-dev] Python Software Foundation seeksmentors and students for
Google Summer of Code
- `New artwork for the osx port
- `[Python-checkins] Python Regression Test Failures refleak (1)
- `PEP 8 pylintrc?
- `Compiling w/ C++ (was: Reducing memory overhead for dictionaries by
removing me_hash)
- `Builtin exit, good in interpreter, bad in code.
- `Buildbot messages and the build svn revision number
- `Google Summer of Code proposal: New class for work with binary
trees AVL and RB as with the standard dictionary.
- `gettext.py bug #1448060
- `SoC proposal: "fix some old, old bugs in sourceforge"
- `[Mono-dev] IronPython Performance
- `[IronPython] [Mono-dev] IronPython Performance
- `interested in Google Summer of Code: what should I do?
- `EuroPython 2006: Call for papers
- `GNU info version of documentation
- `big-memory tests
- `suggestion: except in list comprehension
- `Accessing DLL objects from other DLLs
- `Addressing Outstanding PEPs
- `PEP 304 (Was: Addressing Outstanding PEPs)
- `inheriting basic types more efficiently
- `Google Summer of Code proposal: New class for workwith binary trees
AVL and RB as with the standard dictionary.
- `A better and more basic array type
- `Type-Def-ing Python
- `traceback.py still broken in 2.5a2
- `"mick-windows" buildbot uptime
- `rest2latex - was: Re: Raising objections
- `Is this a bad idea: picky floats?
- `Summer of Code mailing list
- `Bug day? <http://mail.python.org/pipermail/python-dev/2006-April/064552.html>`__
- `Float formatting and #
- `Crazy idea for str.join
- `rich comparisions and old-style classes
- `methods on the bytes object (was: Crazy idea for str.join)
- `Problem with inspect and PEP 302
- `PyThreadState_SetAsyncExc and native extensions
- `__getslice__ usage in sre_parse
- `elimination of scope bleeding of iteration variables
- `[Python-3000] in-out parameters
- `socket module recvmsg/sendmsg

More information about the Python-Dev mailing list