[Python-Dev] python-dev Summary for 2003-07-01 through 2003-07-31 [draft]

Brett C. bac at OCF.Berkeley.EDU
Mon Aug 4 21:00:33 EDT 2003

Here is the rough draft of the Summary for the month of July (once again 
I combined two summaries into a single month-long summary since I 
couldn't get to the earlier summary soon enough to warrant a separate 
release).  As usual you guys have a day or so to send in corrections.

I would appreciate not just correctional feedback but just overall 
feedback as well for this summary.  I have changed the format once again 
as well as the general philosophy behind the Summaries in preparation 
for when I start grad school and have to cut back on the breadth of the 
Summaries.  You can read the Summary Announcements section to see what 
and why I have changed.  Any feedback is appreciated.


python-dev Summary for 2003-07-01 through 2003-07-31
This is a summary of traffic on the `python-dev mailing list`_ from July 
1, 2003 through July 31, 2003.  It is intended to inform the wider 
Python community of on-going developments on the list and to have some 
impact or hold interest to the wider Python community.  To comment on 
anything mentioned here, just post to python-list at python.org 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-first/twenty-second summary written by Brett Cannon 
(who is still learning how to count; gave the wrong summary count last 

All summaries are archived at http://www.python.org/dev/summary/ .

Please note that this summary is written using reStructuredText_ which 
can be found at http://docutils.sf.net/rst.html .  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: http://www.python.org/peps/pep-0012.html

The in-development version of the documentation for Python can be found 
at http://www.python.org/dev/doc/devel/ and should be used when looking 
up any documentation on something mentioned here.  Python PEPs (Python 
Enhancement Proposals) are located at http://www.python.org/peps/ .  To 
view files in the Python CVS online, go to 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ .

.. _python-dev: http://www.python.org/dev/
.. _python-dev mailing list: 
.. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
.. _Docutils: http://docutils.sf.net/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html

.. contents::

.. _last summary: 

Summary Announcements
It's experimentation time again!  In preparation for having to cut down 
on the breadth of the summary thanks to my return to school I am 
starting this summary off as the inaugural release of the new format. 
Pretty much everything is going to change somewhat.

First, though, I think I should explain my new viewpoint towards the 
summaries that I am taking.  In order to continue to provide a certain 
level of quality and coverage while retaining my personal sanity and to 
not feel like the Summaries are a job instead of something I do for fun 
and to help others, I am going to start viewing the Summaries more from 
a journalistic perspective than a historical one.  Before I felt more 
like a historian that was summarizing *everything* that happened on 
python-dev.  Now, though, I am be more like a journalist, covering only 
the pertinent ideas.  This also allows me to inject more of my 
personality into my writing.

But what ramifications does this new perspective cause?  Well, it will 
dictate what I do and do not summarize.  I plan on several types of 
discussions to be covered in the Summaries.  One is new features of the 
language.  This is so people can know about them ASAP and thus comment 
on them.  Since practically any feature mentioned here is experimental 
there is a chance to remove it if a community movement mounts.  I will 
also cover any major thinking on the future of Python.  I have always 
wished there was an easy way to see what pie-in-the-sky ideas python-dev 
was thinking of in the back of our collective mind; the summaries might 
as well fill this desire.  And of course any random discussion that is 
large, important, and/or complex will continue to be covered.

In terms of formatting and layout, that will also change along with the 
new viewpoint.  I am planning to follow something more along the lines 
of the Perl's `This Week... 
<http://dev.perl.org/perl6/list-summaries/>`__; yes, I am taking a cue 
from Perl but AM Kuchling and Michael Hudson originally used this format 
as well.  This means titles of summary sections will more reflect the 
topic being summarized rather than the specific thread(s).  I will 
continue to list all of the threads that contributed to the summary, 
though, for reference purposes.  I feel this will be beneficial since I 
know I have personally looked back into the Summary archives and had a 
hard time finding something specific since the subject of a thread does 
not always match the topic of discussion; if I can't find something and 
I know about what month it happened I can only imagine what everyone 
else has had to go through to find something!

I am removing the Quickies section from the Summaries.  This section was 
nice to have, but it just ate away at my time.  This also goes along 
with the new viewpoint.

I am sure not everyone will be happy with this change, that's fine.  But 
if someone out there *truly* hates the direction I am going then they 
can step forward and take the reigns from me.  But as I have stated 
before, the fine print on me giving up this post is that the person who 
takes over must be as thorough as I *used* to be; I can do the summaries 
in a half-assed fashion as well as anyone else.

Enough of that topic.  One thing I would like to mention is that the 
`Python Software Foundation`_ can now accept donations through PayPal. 
Specifics can be found at http://www.python.org/psf/donations.html .  It 
would be great if people could donate since the PSF is more than just a 
non-profit to hold the Python intellectual property.  One of the goals 
of the group is to get enough money to do something like the Perl 
Foundation does and sponsor someone to hack on Python for a living for a 
set amount of time.  Right now we are a ways off from having that kind 
of revenue, but there is no reason why we can't.  Heck, if we can just 
get enough to sponsor one person to do full-time Python hacking for a 
week it would be beneficial.  Or better yet, the PSF could sponsor one 
of their own members to write a summary of the python-dev mailing list 
for the betterment of the community.  =)

.. _PSF:
.. _Python Software Foundation: http://www.python.org/psf/
.. _PayPal: http://www.paypal.com/

Python 2.3 final released!
In case for some odd reason you didn't know, Python 2.3 final has gone 
out the door.  The team managed to meet the goal of getting it out by 
the end of the month so that Apple_ can use a final release instead of a 
release candidate in OS X 10.3 (a.k.a. Panther).

The goal of this release was to continue to improve Python without 
adding any new keywords.  This was met while speeding things up, fixing 
bugs, adding to the standard library, and adding some new built-ins.  To 
find out what is new or has changed look at the changelog at 
http://www.python.org/2.3/highlights.html or `What's New in Python 2.3`_.

As with all software, there are bound to be bugs.  What bugs that are 
known are listed at http://www.python.org/2.3/bugs.html .  If you find 
bugs not listed there, please report them on the SourceForge bug tracker 
at http://sourceforge.net/tracker/?group_id=5470&atid=105470 .  Running 
the regression test suite (details on how to do this is covered in the 
documentation for the 'test' package as found at 
http://www.python.org/doc/current/lib/module-test.html) is always 

Contributing threads:
     - `Problem with 2.3b2 tarfile?`__
     - `MacPython 2.3b2 binary installer for MacOSX`__
     - `Running tests on freebsd5`__
     - `Python 2.3 release schedule update`__
     - `Vacation and possibly a new bug`__
     - `Doc/ tree closes at noon, US/Eastern`__
     - `I've tagged the tree`__
     - `cygwin errors`__
     - `test_strptime; test_logging; test_time failure`__
     - `2.3rc1 delayed`__
     - `Python 2.3 release candidate 1`__
     - `post-release festivities`__
     - `New branch for r23c2 work`__
     - `Serious CallTip Bug in IDLE`__
     - `MacPython-OS9 test failures`__
     - `Doc/ tree on trunk closed`__
     - `Cutting the 2.3c2 tonight 8pm EDT`__
     - `Re: [Python-checkins] python/dist/src/Misc NEWS,1.826,1.827`__
     - `RELEASED Python 2.3c2`__
     - `2.3rc2 IDLE problems on a Win2000sp3 box`__
     - `Draft: 2.3 download page`__
     - `Last priority >= 7 bug for Python 2.3`__
     - `CVS Freeze`__
     - `RELEASED Python 2.3 (final)`__

__ http://mail.python.org/pipermail/python-dev/2003-July/036669.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036732.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036762.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036783.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036845.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036892.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036899.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036900.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037117.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036921.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036940.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036941.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037024.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037134.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037144.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037193.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037200.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037207.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037208.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037237.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037284.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037311.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037315.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037319.html

.. _Apple: http://www.apple.com/
.. _What's New in Python 2.3: http://www.python.org/doc/2.3/whatsnew/

String Exceptions Going Extinct, Eventually
It has been brought several times before, but things are now moving 
along to eventually deprecated string exceptions (e.g., ``raise "this 
string exception"``).  they have now been removed from the tutorial to 
prevent people new to the language from picking up habits that will 
eventually be impossible to perform.

As for when the impending deprecation will occur only Guido knows.  The 
chances of it coming before Python 3, though, is most likely small.

Contributing threads:
     - `String exceptions in the Tutorial`__

__ http://mail.python.org/pipermail/python-dev/2003-July/036665.html

Someday, My CVS updates Will Succeed on the First Try...
We all know that SourceForge_ does not have the snappiest or most 
reliable CVS_ servers in the world; Python 2.3 final's release was 
targeted a few days earlier than needed for Apple_ in case SF's CVS went 
down.  Solutions to how to deal with this problem have come up.

One specific problem that people are trying to solve is the poor 
anonymous pserver access.  SF has their CVS servers set up so that 
authorized CVS commands take priority over anonymous ones and thus  when 
there is heavy traffic anonymous CVS basically shuts down.  Martin v. 
Löwis put up a link to a nightly tarball at 
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python.tgz of the CVS 
HEAD.  perl.org has provided a nightly tarball as well at 
http://cvs.perl.org/snapshots/python/ for quite some time now.  The 
suggestion of having a read-only version of the CVS tree on python.org 
was came up, but how to properly do it and who would set it up was not 

And of course there is always the option of moving CVS off of SF 
entirely.  There is one offer on the table with the caveat that we need 
to know what kind of bandwidth demands we would have.  Another offer 
sprung up this month from Michal Wallace to host our CVS at 
http://www.versionhost.com/ with the hitch that the server would be 
pserver only which would thus most likely only work for anonymous checkouts

Contributing threads:
     - `alternate pserver access for python CVS?`__
     - `[fwd] SourceForge status`__
     - `Volunteering to help with pserver cvs on python.org`__

__ http://mail.python.org/pipermail/python-dev/2003-July/036699.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036708.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036860.html

.. _SourceForge: http://www.sf.net/
.. _CVS: http://www.cvshome.org/

Which License to Use?
Domenico Andreoli wanted to donate `python-crack`_ to the PSF_ and 
wondered what steps would be necessary to do so.  He was first told that 
the module would not be included in Python since it is too specific. 
Secondly, it was suggested he not choose the PSF license.  Instead, he 
was told that he should use the BSD or MIT license (both of which can be 
found at http://www.opensource.org/licenses/index.php); clean, simple 
licenses that are not viral like the GPL but are GPL-compatible.  This 
is so that it can be included in any software that uses Python.

Contributing threads:
     - `donating python-crack module`__

__ http://mail.python.org/pipermail/python-dev/2003-July/036712.html

.. _python-crack: http://savannah.nongnu.org/projects/python-crack

Not Quite ANSI C
Every so often someone runs Python against a C code checker and notices 
failures that get reported to us.  Often, though, we have to tell the 
person that we already know of the failures and that there is nothing to 
worry about.  This time it was failures under Purify.  We have also 
received reports of failures under Valgrind_ which are spurious.  The 
language isn't even fully ANSI C compliant, but as Tim Peters said, 
"it's not possible to write a useful and portable memory allocator in 
100% standard ANSI C" among other reasons why strict ANSI C conformity 
is broken.  The only major violations in the code are casting a pointer 
to a unsigned integer type and assuming "that whatever memory protection 
gimmicks an OS implements are at page granularity" which is a minor sin 
at best.  There is also some cases of accessing memory without proper 

Contributing threads:
     - `Invalid memory read in PyObject_Free`__
     - `strict aliasing and Python`__

__ http://mail.python.org/pipermail/python-dev/2003-July/036717.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036898.html

.. _Valgrind: http://developer.kde.org/~sewardj/

Shadowing Built-ins is Becoming a No-No
Before the code was removed, Python 2.3 raised a DeprectionWarning when 
you overshadowed a built-in in a module from outside the module's actual 
code.  What this means is that doing something like::

     import mod
     mod.reload = 42

would raise the warning.  Now doing ``reload = 42`` in the module itself 
would still be allowed.  The idea was (and still is) that the compiler 
can know when a built-in is shadowed in a module when it compiles the 
module's code.  But allowing someone to overwrite a built-in externally 
means that the compiler cannot make any assumptions that built-ins will 
forever reference the actual built-in code.  This is unfortunate since 
if shadowing externally was made illegal the compiler can reference the 
built-in code directly and skip some steps for a nice speed-up.

This is why there was code to warn against this initially.  But it 
didn't work well enough to be left in Python 2.3 so it has been removed. 
  But this restriction will most likely be enforced at some point so it 
is something to keep in mind.

Contributing threads:
     - `Deprecation warning 'assignment shadows builtin'`__...
     - `DeprecationWarning: assignment shadows builtin`__

__ http://mail.python.org/pipermail/python-dev/2003-July/036767.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036879.html

While Python 2.3 sees up to a 30% speed increase over 2.2, it still 
starts up slower.  Originally it was believed that it was because of the 
importation of the re module.  Marc-André Lemburg applied a patch that 
tried to minimize its possible importation at startup but it was still slow.

Jeremy Hylton pointed out that 2.2.3 imported re so that probably was 
not the problem.  One thing that is different, though, is the automatic 
inclusion of warnings, codecs, and the ability to do zip imports.  These 
three things pull more modules and all of this leads to a longer startup 
time.  There is also the importation of distutils thanks to the site.py 
module, but that only occurs if you execute in a build directory.

Including zip imports also got attacked for  the number of failed checks 
for files it can incur.  But it is believed this is not as bad as all of 
the extra imports being done now and Just van Rossum said he would try 
to cut down the unneeded checks in the future.

Contributing threads:
     - `2.3 startup speed?`__

__ http://mail.python.org/pipermail/python-dev/2003-July/036815.html

The World and Numbers
People might not be aware of it, but locale.setlocale never changes the 
LC_NUMERIC locale value.  This is so that 'str' and 'float' can return 
and receive numbers in a consistent way in source code.  This causes a 
problem, though, for people in locales that do not use a period for a 
decimal point.  If you had your locale set to Brazilian and tried to 
pass the string "3,14" to 'float' it would fail even though that is a 
legitimate number representation for your locale.

The suggestion become to have a locale-agnostic version of 'str' and 
'float' in the locale module for people to use when they needed such 
functionality.  It has now reached the stage of a rough draft PEP as 
found at http://mail.python.org/pipermail/python-dev/2003-July/036996.html .

Contributing threads:
     - `LC_NUMERIC and C libraries`__
     - `Be Honest about LC_NUMERIC`__
     - `RE: [Spambayes] Question (or possibly a bug report)`__

__ http://mail.python.org/pipermail/python-dev/2003-July/036869.html
__ http://mail.python.org/pipermail/python-dev/2003-July/036996.html
__ http://mail.python.org/pipermail/python-dev/2003-July/037178.html

Zippin' Nothin'
The built-in 'zip' function in Python 2.3 raises TypeError when given no 
arguments.  This causes problem when you do ``zip(*args)`` and args is 
empty.  So for Python 2.4 'zip' with no arguments will return an empty list.

Contributing threads:
     - `zip() in Py2.4`__

__ http://mail.python.org/pipermail/python-dev/2003-July/037332.html

A Syntax For Function Attributes
An old debate (or at least old in terms of it having popped up multiple 
times during the tenure of your author) has been ways of enhancing 
function definitions.  Previously it has been over ways to make defining 
classmethod and its ilk in a cleaner fashion along with properties (past 
summaries on this can be found at 

What made the discussion slightly different this time, though, was the 
focus was on function attributes specifically.  One idea was to tweak 
Michael Hudson's bracket syntax for method annnotations to allow for 
function attributes; ``def foo() [bar=42]: pass``.  Another suggestion 
was to take the dictionary-like connection even farther; ``def foo() 
{bar=42}: pass``.  There was no clear winner in either case partially 
because this discussion flared up towards the end of the month.

It was also pointed out that using Michael Hudson's method descriptors 
you could come up with a wrapping function that handled the situation::

     def attrs(**kw):
         def _(func):
             for k in kw:
                 setattr(func, k, kw[k])
             return func
         return _

     def foo() [attrs(bar=42)]: pass

Perk of this is it does not lead to any special syntax just for function 
attributes.  One drawback, though, as pointed out by Paul Moore is that 
this makes the method annotation idea a little to liberal and open to 
hackish solutions like this that will lead to abuse.  This was not a 
huge worry, though, since almost anything can be abused and this is all 
already doable now, just without a nice, clean syntax.

Contributing threads:
     - `A syntax for function attributes?`__

__ http://mail.python.org/pipermail/python-dev/2003-July/037338.html

More information about the Python-Dev mailing list