This is a summary of traffic on the python-dev mailing list from August 16, 2004 through August 31, 2004. 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 comp.lang.python (or email python-list at python dot org which is a gateway to the newsgroup) 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 forty-seventh summary written by Brett Cannon (new type of coverage, same kind of sarcasm).
To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there.
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; it's 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.
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 new code; otherwise use the current documentation as found at http://docs.python.org/ . 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.
The Python Software Foundation is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps.
After asking people last week about how they wanted me to change the python-dev Summary as as to allow me to retain my free time, all respondents unanimously went with the option of letting me choose what I wanted to cover. That made me happy for a couple of reasons. One is that it makes the summaries more enjoyable for me since I mostly cover stuff I like and thus should be less bored at points while writing. It also flattering in a way that people trusted what I would cover enough to not want to suggest what I should cover. It also allows me to spend more time on python-dev participating than sitting on the sidelines dreading have to summarize some 100 email thread on whether we should move over to VC 7 or something (can you tell I was bored out of my skull by that thread?).
So this summary starts the new coverage style. As you can see it is much shorter than normal since I didn't try to be as thorough (7 pages compared to the usual 10-20). But I think this style allows what I do summarize to have more details than it would normally have; quality over quantity. I have reintroduced the "Skipped Threads" section of the Summaries so people can see what I skipped in case there is something they might want to read that I just didn't care about. In places where I remember something partially relevant I added a sentence on it so it isn't just a list of subject lines.
PEP 3000 (Python 3.0 Plans) came into creation. This text's point of existence is to list changes known to be planned for Python 3.0 and not hypothetical (Guido suggested all hypothetical talk call the version Python 3000, partially for marketing purposes). Plus I am a co-author and it finally completes my time in the School of Hard Knocks. =)
PEP 333 (Python Web Server Gateway Interface v1.0) proposes a "standard interface between web servers and Python web applications or frameworks, to promote web application portability across a variety of web servers".
PEP 309 (Partial Function Application) was updated with some details.
PEP 334 (Simple Coroutines via SuspendIteration) came into existence to suggest coming up with some form of lightweight coroutines.
While the hubbub over using a character for decorators was brewing, people began suggesting reserving a character that would never be used in Python for anything. The thought was that people who wanted to use a character to represent application-specific information could use the reserved symbol and not have to worry about clashing with possible future features like Leo and IPython are with the use of '@'. But no reservation of a character occurred.
Towards the end of the month, to meet the a3 deadline, a unified proposal from the community came forward led by Robert Brewer and Michael Sparks. They pushed the J2 proposal:
using: somedecorator staticmethod def func(): pass
Guido contemplated the proposal, saying "it got pretty darn close" to being accepted, but in the end decided not to. For Guido's full reasoning see http://mail.python.org/pipermail/python-dev/2004-September/048518.html . But he said he had two key issues. One was the indentation "suggests that its contents should be a sequence of statement, but in fact it is not". Issue two was that using a keyword to start a line was a real attention grabber and that "using" did not deserve this.
The topic of how the whole decorators situation was handled was touched upon. He realized that "dramatic changes must be discussed with the community at large". He was also impressed by how the community pulled together to propose an alternative as it did and hopes to see more proposals of the same quality in the future.
So now what? Guido said that he would be willing to change the character used for decorators for 2.4b1 . That means if '@' drives you nuts but something else like '!' works for you then speak up and try to get the community to rally behind it.
Python has had a simple peephole optimizer in the compiler since 2.3 that optimized imported bytecode. Raymond Hettinger moved it up, though, so that the optimization would be saved to .pyc files and thus remove the need to repeat the process every time.
Guido questioned this move. He thought that since it was an optimization it should fall under the -O command-line option.
But then people came forward to suggest that Raymond's move was good, saying that the cost of the optimization was non-existent and thus should be used. I brought up the point that a definition of what should be considered an optimization; anything that changes the initial opcode, or something that takes extra time/memory or changes semantics? Tim Peters stepped forward and said that since the optimizations were so simple that he thought they should be kept. David Abrahams also came forward and said they should be kept to get more testing on them since they were not complex and thus did not influence debugging of code.
In the end Raymond's change was kept in place.
Python 2.4a3 has been released. As usual, please download it, run the regression tests, and report any errors you get. Since this will be the last alpha this is your last chance to get new features in before b1 comes out.
The use of priorities on the SourceForge tracker has also been clarified. Anything set to 9 must be dealt with before the next release. Priority 8 is to be dealt with before b1; it changes functionality so if it isn't in by b1 it won't be in until the next version. Priority 7 is for something that should get in before the final release. Anthony Baxter also gained sole control of setting the priority so as to keep the settings consistent.
Stemming from a conversation about moving Python over to Unicode only for string representation for 3.0, the discussion of a bytes type came up. People were saying they used str to store binary data and that if str went away or no longer represented straight binary data (since Unicode has different encodings the values can change while meaning the same thing in terms of characters) they would need a way to deal with this.
The idea that the array module solved this was basically dismissed since it seemed more built-in support was needed for convenience. It also meant more flexibility in terms of what interfaces were implemented. There was also some issues with getting array to work the exact way people wanted it to.
The next question was whether literal support was needed. Would you really need to write something like b"\x66\x6f\x6f" instead of bytes([0x66, 0x6f, 0x6f])?
How all of this would play with Unicode ended up being discussed. In the end it seemed that one could encode and decode back and forth but that all work with character should be in Unicode and only decoded into bytes on the I/O barrier (writing to disk or the network, for instance) to minimize any possible encoding errors and to make usage easier.
Mutability came up. Being mutable would be handy, but it killed its usage as a dictionary key. It was suggested that bytes hash to a tuple of integers representing the bytes, but nothing more was said. But in general almost everyone agreed that having the bytes type be mutable was best.
PEP 332 was sketched out during the early part of this discussion, but has not been updated since it died down.
PEP 292`_ (Simpler String Substitutions) got a huge amount of discussion this past two weeks. Ignoring the syntax discussions (that was decided long ago before the PEP was accepted and had consensus and thus was a moot point) and the discussion of whether a trailing $ at the end of the substitution pattern should be considered an error or not (it is), a couple of topics were discussed.
To make this summary easier to follow, realize that the class that implements PEP 292 is named "Template" and thus I will just refer to the implementation by that name.
The first topic was over whether Template should return Unicode objects. The side supporting it pointed out that Python 3.0 was going to be using Unicode for strings exclusively so it would be good to start using them now. It also went with the initial design of PEP 292 which was to help with i18n where Unicode is constantly used.
People against, though, didn't want to suddenly be given a Unicode object when a string was used for template string passed in. That would be too surprising and lead to inconsistent usage thanks to sudden mixing of strings and Unicode objects in code. This issue was resolved by no longer subclassing unicode but making it easy to subclass Template so as to add direct Unicode support with ease.
The second issue was other the design of the API. Originally Template was a class that overrode __mod__ to make it work like string interpolation works now for str and unicode. But then some people felt a class was too heavy-handed if there was no way to change the way Template worked through a subclass. This obviously led to a desire for functions to do the work for both Template and SafeTemplate (similar class to Template that left in substitution points if they didn't match any values in the dict passed in).
In the end the class design was kept thanks to Tim Peters and metaclasses. Tim came up with a neat way to have the regex be generated at class creation time through a metaclass and thus allow subclasses to change how Template matched substitution points and such, all without a performance hit at instance creation time. Use of __mod__ and the SafeTemplate class were removed and Template grew substitute and safe_substitute methods. Practically everyone at this point seems happy with the design so it has been implemented and checked in.
Anthony Baxter suggested banning use of mangled private names (names starting with __) in the stdlib. His argument was that they are a hack and the stdlib is supposed to act as a good example and that name mangling was not good.
Guido essentially agreed with the caveat that some uses of private names is justified such as if a private name is storing the equivalent of a 'friend' function from C++.
Warnocked (i.e., emails that get essentially no response) emails very insignificant threads are not listed