python-dev Summary for 2003-08-01 through 2003-08-15

Brett C. bac at OCF.Berkeley.EDU
Mon Aug 18 23:49:25 CEST 2003

python-dev Summary for 2003-08-01 through 2003-08-15
This is a summary of traffic on the `python-dev mailing list`_ from 
August 1, 2003 through August 15, 2003.  It is intended to inform the 
wider Python community of on-going developments on the list.  To comment 
on anything mentioned here, just post to python-list at or 
`comp.lang.python`_ with a subject line mentioning what you are 
discussing. All python-dev members are interested in seeing ideas 
discussed by the community, so don't hesitate to take a stance on 
something.  And if all of this really interests you then get involved 
and join `python-dev`_!

This is the twenty-third summary written by Brett Cannon (about to move 
for the umpteenth time).

All summaries are archived at .

Please note that this summary is written using reStructuredText_ which 
can be found at .  Any unfamiliar 
punctuation is probably markup for reST_ (otherwise it is probably 
regular expression syntax or a typo =); you can safely ignore it, 
although I suggest learning reST; its simple and is accepted for `PEP 
markup`_ and gives some perks for the HTML output.  Also, because of the 
wonders of programs that like to reformat text, I cannot guarantee you 
will be able to run the text version of this summary through Docutils_ 
as-is unless it is from the original text file.

.. _PEP Markup:

The in-development version of the documentation for Python can be found 
at and should be used when looking 
up any documentation on something mentioned here.  Python PEPs (Python 
Enhancement Proposals) are located at .  To 
view files in the Python CVS online, go to .

.. _python-dev:
.. _python-dev mailing list:
.. _comp.lang.python:
.. _Docutils:
.. _reST:
.. _reStructuredText:

.. contents::

.. _last summary:

Summary Announcements
Well, Michael Chermside responded to my question from the last summary 
about whether the new format and style of the Summaries was good.  Once 
again a single person has led to how the summaries will be handled.  You 
guys need to speak up (although I like the side that won this time  =)!

I am playing with layout once again.  This time I am changing how the 
"contributing threads" lists are formatted.  I know some of you hate 
inlined links in reST markup, but when these lists become huge it 
becomes really hard to keep track of the URIs when I have to list them 
away from the actual item on a separate line below the list of thread names.

With `Python 2.3` out the door bug reports have started to come in. 
Work on 2.3.1 has begun.  Please keep running the regression tests 
(easiest way is to run either ``make test`` or run in the 
test package; see the docs for the test package for help).

On a personal note, if anyone knows of any Python users and such in the 
San Luis Obispo area of California, drop me a line at brett at


Python user helping Parrot?  Treacherous!
Michal Wallace decided to get AM Kuchling's `previous work 
<>`__ on getting Python code to run 
on the Parrot_ virtual machine (which is what Perl 6 will use).  Well, 
the rather nutty fellow managed to get pretty damn far with it as shown 
at .  Michal was 
actually almost done with handling pure Python code and was getting 
ready to try to figure out how to get Parrot to handle C extension 
modules with that being the biggest sticking point.

Since Parrot is not Python it does not have a parser for Python code; 
problem if your code has an exec statement.  This turned out to not be a 
worry, though, since there are pure Python parsers out there.

All of this has direct relevance to python-dev because of the bet 
between Guido and Dan Sugalski, developer of Parrot.  The rules are 
outlined at 
.  What is going to happen at OSCON 2004 is a benchmark program written 
in pure Python will be run using a CVS checkout of Python against a 
Parrot (after converting the bytecode to Parrot's own bytecode) 
checkout; slowest implementation's author gets a pie in the face, buy 
the winner's dev team a round of beer, and $10.

So why have this bet?  This was discussed and basically came down to 
finding out whether Parrot really can run Python fast.  Parrot wants to 
be the VM for as many languages as possible, including Python.  This 
acts as a way to motivate people to see how feasible this is.

And don't think that the CPython interpreter will disappear if Parrot 
wins.  Dan pointed out that even if he did win the bet that Guido would 
probably want to keep CPython around since that is under his control and 
allows testing out new language features much easier then having to deal 
with Parrot and an external dev team.  In other words, let other people 
worry about forcing a Python-shaped peg into a Parrot-sized hole.

.. _Parrot:

Contributing threads:
   * `pirate (python+parrot) 

python-mode gets its own SF project; Vim users laugh
Barry Warsaw, citing lack of time to "properly maintain python-mode.el", 
has created a SourceForge project for the Emacs mode at .  This means all bug reports, 
patches, etc. should be done at that project.

Martin v. Löwis suggested removing `python-mode.el`_ from Python itself 
and to get it distributed with Emacs_ and XEmacs_.  This way there does 
not have to be any synchronization between the new SF project and the 
Python CVS tree.  As of right now, though, python-mode.el is still in 
the Python CVS.

And to give equal billing to Vim_, my code editor of choice, since it 
does not get as much coverage on python-dev as XEmacs does, here are 
some scripts you might want to check out:

taglist.vim :
     "provides an overview of the structure of source code files" by 
splitting the window.
python_fold.vim :
     "This script uses the expr fold-method to create folds for python 
source code."
vimDebug :
     " integrates your favorite debugger with vim."

.. _python-mode.el:
.. _Emacs:
.. _XEmacs:
.. _Vim:

Contributing threads:
   * `New python-mode project at SourceForge 
   * New place for python-mode bug reports and patches 

Caching tuple hashes
Raymond Hettinger asked if there was any reason why tuples, being 
immutable, didn't cache their hash values.  Strings cache their hashes 
and they are immutable, so it seem to make sense.

It was pointed out, though, that tuples could contain an object that 
changed its hash value between hash calls.  Guido said, though, that it 
was the responsibility of the object and not tuples to worry about 
keeping a consistent hash value.

Guido also explained why strings cache their hashes.  It turns out that 
since strings are used so often for keys in dicts that caching their 
hashes gave a large performance boost for almost any program, so the 
effort was felt justified.  But Guido did not see this same 
justification for tuples.  Thus tuples will not cache their hash values.

Contributing threads:
   * `Caching tuple hashes 

PyCon 2004 is under development
Preparation for PyCon_ 2004 have now begun.  With us getting the ball 
rolling much earlier this conference should turn out to be even better 
than last year (which, in my opinion, was great)!  You can go to to find links to lists to get 
involved in organizing or just to be kept abreast of new developments.

.. _PyCon:

Contributing threads:
   * `PyCon DC 2004 Kickoff! 

Let the fixing of 2.3 begin!
The maintenance branch of Python 2.3 (named release23-maint) has been 
created in CVS.  Several bugs have already been fixed.  For instructions 
on how to check out a copy of the branch, read .

Contributing threads:
   * `Python 2.3 maintenance branch is now open 

When a void doesn't equal an integer
After clearing up the confusing issue of the difference between a Python 
int and a Python Integer (the former is <type 'int'> while the latter is 
the union of <type 'int'> and <type 'long'> which is what Python is 
moving towards so that the distinction practically disappears), the 
discussion of how to handle a quirk of Win64 commenced.  It turns out 
that Win64 thinks that ``sizeof(void *) > sizeof(long)`` is a reasonable 
thing to do.  Well, all other platforms now and most likely for the rest 
of Tim Peter's life (at least according to Tim's guess) don't and won't 
hold this to be true.

As of right now Python claims that a void pointer can be held in a 
Python int, but Win64 breaks that claim.  Do we muck around with 
Python's internals for this one strange exception that does not make 
sense, such as making Python ints use long long?  No, of course not. 
Code would break, let alone the added complexity.  So the needed changes 
to the failing tests were dealt with and all seems to be fine with the 
world again ... well, Win64 is still thinking on crack, but that is 
someone else's problem.

Contributing threads:
   * `sizeof(long) != sizeof(void*) 

Where do I put all of my packages?!?
As it stands now there are four places where packages can reside:

1. standard library
2. site-packages
3. site-python (on UNIX this is the same directory where your python2.3 
directory exists)
4. PYTHONPATH environment variable

It was pointed out that this does not necessarily give one all the 
options one might want.  The above covers the Python core easily, but 
there is not clear distinction for vendor packages, network-installed 
packages, system-wide packages or user-installed packages; they are 
covered by 2-4 above.  The suggestion was to make more distinct places 
available for installation and to make distutils aware of them.

A good way to see how this would be useful is to look at how OS X's 
Panther will handle Python 2.3 .  It will have the standard library in 
the standard location of /usr/local/python2.4 .  In that directory, the 
site-packages directory is a symlink to a more system-aware location. 
This is fine but what about a sysadmin who would rather avoid the 
possibility of breaking OS X by messing with the OS's Python 
installation?  What about a user on that system who does not have root 
but wants to have their own place to put their packages?  There is 
definitely room for adding more standard path locations for package 

A PEP was being mentioned but appears to not have been written yet.

Contributing threads:
   * `Multiple levels of site-packages 

Be careful with __slots__
Raymond Hettinger observed that using __slots__ or overriding 
__getattribute__ fails silently when mistakenly used with old-style 
classes.  This has bitten him and others in the bum so he wanted to add 
warning/error messages.  Guido recommended passing on the warnings 
because 1) those are "expert use only" tools, 2) PyChecker can already 
detect the issue, and 3) there are other new-style/classic issues cannot 
as readily be flagged.

It should be known that "__slots__ is a terrible hack with nasty, 
hard-to-fathom side effects that should only be used by programmers at 
grandmaster and wizard levels".  So only use __slots__ if you can apply 
the label of "programmer at grandmaster or wizard level" to yourself 
without your programming peers laughting their bums off; you have been 

Contributing threads:
   * `Make it an error to use __slots__ with classic classes 

Plugging leaks
Michael Hudson thought he had discovered a leak somewhere and went off 
on a little hunt.  It turned out to be a red herring more or less, but 
there was some discussion on the best way to find leaks through 
regression tests.

The basic scheme that everyone seemed to use was to run the regression 
test once to get any caching out of the way and then run the test a set 
number of times and see if the reference counts seemed to grow.  Michael 
Hudson posted a diff to add such a testing feature to test/ 
at . 
  Tim Peters also posted a link to Zope's test driver at which includes a class named TrackRefs 
which can help keep track of the leaked references as well as leaked 

Contributing threads:
   * `CALL_ATTR patch 
   * `refleak hunting fun! 

Making the interpreter its own executable
As it stands now the Python interpreter is distributed as a bunch of 
files mostly made up of the standard library.  But wouldn't it be nice 
if you could make the interpreter just a single executable that was easy 
to distribute with your code?  Well, that discussion cropped up on 
`comp.lang.python`_ at 
.  The idea was to somehow introduce a hook into Py_Main() that could 
harness the new zipimport facility.

The idea came up of appending the stdlib to the end of the Python 
interpreter and to have a flag set to signal that the appending had 
occurred.  The problem is that this could cause unzipping problems.

But setting the flag is not necessarily simple either.  One suggestion 
was to literally patch the interpreter to set the flag.  But there was 
some confusion over the use of the term "patch"; Thomas Heller thought 
more of "link with an object file defining this global variable".

This thread was still going as of this writing and had not yet reached a 
clear solution.

Contributing threads:
   * `hook for standalone executable 

More information about the Python-list mailing list