[since the original mailing of this didn't seem to get to the list I am re-sending] 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@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: 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. 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. ========= 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>`__