[Python-Dev] python-dev Summary for 2003-08-16 through 2003-08-31 [draft]

Brett C. bac at OCF.Berkeley.EDU
Wed Sep 3 02:11:03 EDT 2003

This is a rather light summary, so finding my usual grammatical errors 
shouldn't be too difficult.  With so many people on vacation I will 
probably wait on sending this summary out for a little while.

On a personal note, this is my 24th summary.  What this means is I have 
now written enough summaries to cover a year's worth.  If you care to 
see some stats on the list read the "Summary Announcements" section. 
And if anyone on the list wants the pickled data I have for this or just 
want to know a specific stat I can look it up for you and tell you.


python-dev Summary for 2003-08-16 through 2003-08-31
This is a summary of traffic on the `python-dev mailing list`_ from 
August 16, 2003 through August 31, 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 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-fourth summary written by Brett Cannon (a year's 
worth of summaries by yours truly now under his belt; does this mean I 
am certifiably insane?).

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/ .  Reported bugs 
and suggested patches can be found at the SourceForge_ project page.

.. _python-dev: http://www.python.org/dev/
.. _SourceForge: http://sourceforge.net/tracker/?group_id=5470
.. _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
This is the twenty-fourth summary written by me.  Why am I repeating 
this fact since it is mentioned above?  Well, it is significant because 
this means I have written enough summaries to cover a year's worth of 
email traffic on python-dev (had I not taken a summary off back in 
October this milestone would have been hit for the first half of August 
which represented a physical year since I started doing the summaries). 
  I have managed to see a lot happen on python-dev from a new release, 
the first PyCon, and a number of flame wars.  I personally have managed 
to learn a *huge* amount about not just Python the language but how to 
program in Python, C, and how to handle a large programming project.  It 
has truly been worth the experience.

But how much of an experience has it been?  Well, for a long time now I 
have been planning on writing some code to calculate how much email I 
have read, who wrote most of that email, and what threads made up the 
most.  With my move to San Luis Obispo finished I finally had a chance 
to write said code in an imperfect manner (names, for instance, are a 
pain because some people have their name set differently at different 
computers; "Barry Warsaw" compared to "Barry A. Warsaw"; threads are 
worse thanks to the changing of subject titles in the middle of a 
thread) so as to give me some approximate numbers.

I have read 9469 emails that have passed through the python-dev mailing 
list.  The top six emailers (out of approx. 433 unique emailers) have been:

* Brett Cannon (277 emails when you deal with me just using my last 
initial; 2.9% of all emails)
* Barry Warsaw (305 emails when you also count his middle initial; 3.2%)
* Skip Montanaro (481 emails; 5.1%)
* Martin v. Löwis (627 emails, when calculated looking for all names 
that had "Martin" and "wis" in them; 6.6%)
* Tim Peters (694 emails; 7.3%)
* Guido van Rossum (a whopping 1407 emails; 14.8%)

The average person posted 21.9 emails over the emails I covered.  But 
only about 24 people had more than a single percentage (more than 94 
emails) worth of emails accredited to them.  That means that about 5.5% 
of the unique posters on python-dev accounted for 66.8% of all email 
(and I have gotten to know a good amount of those 24.

As for threads (of which there were *very* approx. 1252 unique threads), 
the top five are:

* "type categories" (115 emails; 1.2% of all emails)
* "PEP239 (Rational Numbers) Reference Implementation and new issues" 
(123 emails; 1.3%)
* "PEP-317" (125 emails: 1.3%)
* "python/dist/src/Python import.c,2.210,2.211" (146 emails; 1.5%)
* "Extended Function syntax" (263 emails; 2.8%)

What does this tell you and me?  First, that I contribute to my own pain 
by more than I thought (I can't believe I emailed that many times!). 
Second, I must *really* like reading.  Third, I have an addiction to 
Python.  Fourth, PEPs really do get discussed.  And fifth, Python 
development is alive and well.

OK, enough statistics.  As for this summary, it turned out rather light 
thanks to a couple of things.  One is the shutdown of mail delivery by 
mail.python.org during the SoBig virus' peak.  This not only cut back on 
the number of emails, but also led to me deleting *a lot* of bogus email 
on my other emails accounts.  My blanket deleting may have caught 
legitimate emails so it is possible I accidently deleted some python-dev 
stuff, although if I did it was minimal.  Another contributing factor to 
the light summary is that a lot of regulars on python-dev were on 
vacation.  This looks like it will happen again for the first half of 
September so expect the next summary to be light as well.

Python using Parrot; new code interpreter or strange evolutionary 
Pirate_ has now reached version 0.01 alpha.  It lacks classes and 
imports but can run a decent amount of Python code.  At least there is 
now a proof-of-concept that Python running on top of the Parrot_ VM is 

.. _Pirate: http://pirate.tangentcode.com/
.. _Parrot: http://www.parrotcode.org/

Contributing threads:
   - `pirate 0.01 alpha! 

Python 2.3.1 on its way?
Raymond Hettinger suggesting pushing for a quick release of Python 2.3.1 
so that the 2.3 branch could be established as a stable version. 
Several bugs and performance enhancements have been committed to the 2.3 
maintenance branch.  Anthony Baxter stepped forward as release czar with 
Raymond Hettinger saying he would help and Barry Warsaw volunteering his 
wisdom as a battle-hardened release czar.

This discussion also brought up the question of whether a .chm help file 
for the Windows distribution would be worth using instead of including 
the HTML distribution of the documentation as it stands now.  It was 
agreed that it was a good thing to have since it allowed for better 
searching.  Tim Peters also discovered the install went faster since it 
would not have to copy a ton of individual HTML files.

Python 2.3.1 has a "verbal" release date of the third week of September; 
there has not been a PEP to set the release schedule officially.

Help would be appreciated in dealing with bug and patch reports on 
SourceForge.  Even if all you do is add a comment saying "this patch 
looks fine" or "I can reproduce this bug" it can be a great help.

Contributing threads:
   - `Py2.3.1 
   - `HTMLHelp for Py2.3.1 
   - `Fixing Patches and Bugs for Py2.3.1 

Making looping generators more efficient
Would you like to see deeply nested generators be more efficient in 
returning their values?  Clark Evans would and made such a request.  He 
essentially wanted to have nested generator calls propogate their values 
to the first non-generator call directly and thus bypass all of the 
generator maintenance code.  There was no direct reaction to this.

Shane Holloway followed with the idea of having special syntax for when 
you yield each value of an iterator.  The idea, once again, would be to 
speed this common case in the interpreter by skipping some bookkeeping 
overhead.  A few syntax versions were offered, but the idea was all the 
same: special-case ``for item in iterable: yield item`` to something 
like ``yield *iterable``.

Contributing threads:
   - `cooperative generators 
   - `Graph exploration with generators 

Use of the logging package in the standard library
Want to help out the development of Python?  Know how to use the logging 
package?  Then python-dev wants you!  There are several modules in the 
stdlib that have home-grown logging code that could (and probably 
should) be using the logging package instead to simplify life.  Read the 
email that started the contributing thread and see if you can't help out 
by converting the module over to using the logging package today!

Contributing threads:
   - `Unification of logging in Python's Standard Library 

Some waxings on PEP 310
PEP 310 proposes the 'with' syntax that came up a while back that 
sparked an immense discussion on python-dev.  The idea was to have a 
more fool-proof way of having an enter and exit method be called before 
executing some specified code.  The common example was acquiring a lock, 
executing some code, and then releasing the lock all without having to 
deal with an explicit try/finally statement.  Samuele Pedroni tried to 
clarify how it should work exactly by requiring __exit__ instead of 
making it optional (read the PEP to understand what this means).

Contributing threads:
   - `PEP 310(with-syntax): close synonym of __exit__ 

Proposed PEP for a 'close' method for generators
Samuele Pedroni has written a pre-PEP on defining a way to have 
generators grow a way to have a 'close' method that is called when their 
execution is finished so as to handle resources correctly.  This is in 
response to not being able to contain yield statements within 
try/finally blocks.

Contributing threads:
   - `pre-PEP: Resource-Release Support for Generators 

email-sig created
Barry Warsaw has created the `email-sig`_ to steer development of 
version 3 of the email package in hopes of having it done for Python 2.4 .

.. _email-sig: http://www.python.org/sigs/email-sig/

Contributing threads:
   - `New SIG: email-sig <New SIG: email-sig>`__

More information about the Python-Dev mailing list