B
Brett C.
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 (e-mail address removed) 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:
http://mail.python.org/mailman/listinfo/python-dev
... _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:
http://www.python.org/dev/summary/2003-08-01_2003-08-15.html
=====================
Summary Announcements
=====================
This is the twenty-fourth summary written by me. This 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). 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 (imperfect because of things
like names which 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 approx. 1252 unique threads, and I
mean approximately), 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, I have an addiction to Python.
Second, PEPs really do get discussed. And third, 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.
=========
Summaries
=========
------------------------------------------------------------------------------
Python using Parrot; new code interpreter or strange evolutionary
parternship?
------------------------------------------------------------------------------
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
possible.
... _Pirate: http://pirate.tangentcode.com/
... _Parrot: http://www.parrotcode.org/
Contributing threads:
- `pirate 0.01 alpha!
<http://mail.python.org/pipermail/python-dev/2003-August/037684.html>`__
------------------------
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
<http://mail.python.org/pipermail/python-dev/2003-August/037687.html>`__
- `HTMLHelp for Py2.3.1
<http://mail.python.org/pipermail/python-dev/2003-August/037866.html>`__
- `Fixing Patches and Bugs for Py2.3.1
<http://mail.python.org/pipermail/python-dev/2003-August/037840.html>`__
----------------------------------------
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
<http://mail.python.org/pipermail/python-dev/2003-August/037708.html>`__
- `Graph exploration with generators
<http://mail.python.org/pipermail/python-dev/2003-August/037738.html>`__
--------------------------------------------------
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
<http://mail.python.org/pipermail/python-dev/2003-August/037743.html>`__
-----------------------
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__
<http://mail.python.org/pipermail/python-dev/2003-August/037795.html>`__
------------------------------------------------
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
<http://mail.python.org/pipermail/python-dev/2003-August/037803.html>`__
-----------------
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>`__
++++++++++++++++++++++++++++++++++++++++++++++++++++
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 (e-mail address removed) 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:
http://mail.python.org/mailman/listinfo/python-dev
... _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:
http://www.python.org/dev/summary/2003-08-01_2003-08-15.html
=====================
Summary Announcements
=====================
This is the twenty-fourth summary written by me. This 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). 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 (imperfect because of things
like names which 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 approx. 1252 unique threads, and I
mean approximately), 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, I have an addiction to Python.
Second, PEPs really do get discussed. And third, 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.
=========
Summaries
=========
------------------------------------------------------------------------------
Python using Parrot; new code interpreter or strange evolutionary
parternship?
------------------------------------------------------------------------------
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
possible.
... _Pirate: http://pirate.tangentcode.com/
... _Parrot: http://www.parrotcode.org/
Contributing threads:
- `pirate 0.01 alpha!
<http://mail.python.org/pipermail/python-dev/2003-August/037684.html>`__
------------------------
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
<http://mail.python.org/pipermail/python-dev/2003-August/037687.html>`__
- `HTMLHelp for Py2.3.1
<http://mail.python.org/pipermail/python-dev/2003-August/037866.html>`__
- `Fixing Patches and Bugs for Py2.3.1
<http://mail.python.org/pipermail/python-dev/2003-August/037840.html>`__
----------------------------------------
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
<http://mail.python.org/pipermail/python-dev/2003-August/037708.html>`__
- `Graph exploration with generators
<http://mail.python.org/pipermail/python-dev/2003-August/037738.html>`__
--------------------------------------------------
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
<http://mail.python.org/pipermail/python-dev/2003-August/037743.html>`__
-----------------------
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__
<http://mail.python.org/pipermail/python-dev/2003-August/037795.html>`__
------------------------------------------------
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
<http://mail.python.org/pipermail/python-dev/2003-August/037803.html>`__
-----------------
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>`__