PEP movements

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.

Contributing threads:

• Minimal 'stackless' PEP using generators?

Decorators "issue" mostly solved

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.

Contributing threads:

• Decorator order implemented backwards?
• Considering decorator syntax on an individual feature
• PEP 318: Suggest we drop it
• __metaclass__ and __author__ are already decorators
• Reserved Characters
• PEP 318: Can't we all just get along?
• Multiple decorators per line
• Important decorator proposal on c.l.p.
• Re: [Python-checkins] python/nondist/peps pep-0318.txt...
• CO_FUTURE_DECORATORS
• decorators: If you go for it, go all the way!!! :)
• Re: Re: def fn (args) [dec,dec]:
• J2 proposal final
• (my) revisions to PEP318 finally done.
• Rejecting the J2 decorators proposal

When should something be put under the great powers of -O ?

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.

Contributing threads:

• Re: [Python-checkins] python/dist/src/Python compile.c, 2.319, 2.320

2.4a3 out the doors so kick those tires!

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.

Contributing threads:

• 2.4a3 release is September 2, SF tracker keywords

Talking about bytes

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.

Contributing threads:

• adding a bytes sequence type to Python
• Byte string class hierarchy

String substitution sure is a touchy subject

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.

Contributing threads:

• Update PEP 292
• PEP 292 - Simpler String Substitutions
• Alternative Implementation for PEP 292: Simple String Substitutions
• Alternative placeholder delimiters for PEP 292

Private names considered rude in the stdlib

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++.

Contributing threads:

• __mangled in stdlib considered poor form