Python 2.3 branch open for fixin'

Anthony Baxter, perpetual release manager for the 2.3 branch, announced that CVS commits for 2.3 were open again. He mentioned he thought another release around May or June would probably happen unless a severe bug came up the required immediate patching and release.

But Jim Fulton discovered a critical bug. =) It has been fixed in CVS, but no word on if the bug's severity has been judged by Anthony to warrant another release now.

Contributing threads:

• release23-maint is reopened for business.

Early Spring cleaning for what platforms Python supports

Skip Montanaro cleaned up the configure.in script for Python and in the process removed old support for unneeded OSs as stated in PEP 11. So SunOS 4 support is gone. There was discussion of making Python 2.4 not support libc 5 since Python does not compile with it. The suggestion was made of having configure.in detect libc 5 and if it found it then refuse to continue.

Skip also removed optional universal newline support and antiquated pthread variants from 1997 and before.

Contributing threads:

• zapped several unsupported bits...
• PEP-0011 up-to-date

Compiling in profiling support for the interpreter

Jeremy Hylton discovered his old way of turning on gprof profiling support when compiling Python no longer worked. Hye-SHik Chang said he got it working by compiling using CC="cc -pg" LDFLAGS="-pg" ./configure. Martin v. Löwis suggested running configure with `` --without-cxx`` to get around the problem.

Contributing threads:

• building python with profiling support

Python and C89 play nicely together

The question of what version of C Python is required to work with came up. The answer is that C89 is the version of Standard C Python requires. Neither C89 with Amendment 1 (also called C95) nor C99 are required for Python to run (which, in this case, meant wchar.h is not required).

Contributing threads:

• *grumble* wchar.h
• Another big ANSI-fication change...

Growing lists just got that much faster

Raymond Hettinger (along with the help of various other people on his initial patch) managed to come up with a way to speed up allocating space for list items (either from growth of an exisiting list or creation of a new list).

While this was being discussed, though, the possibility of 3rd party code messing with the internal values of list items came up. While no specific use-case was found, it was agreed upon that code outside of the Python core should not break the API; there is no guarantee the internals won't change.

Raymond has also subsequently done a major clean-up of the entire PyList API that has netted wonderful speed-ups across the board. And in case you are a big fan of list.pop(0) and list.insert(0, x), the collections module's deque object now handles your needs in a much faster fashion. Kudos to him for doing all of this and helping to make sure Guido doesn't get a pie at OSCON 2004 (if you don't catch that reference about the pie, read http://python.org/dev/summary/2003-12-01_2003-12-31.html#pie-thon-competition-work-ramps-up )

Contributing threads:

• Optimization of the Year

Do we really need mutability for exceptions groups?

The question was raised as to why except (TypeError, ValueError): is acceptable while except [TypeError, ValueError]: (in other words why use tuples to group exceptions for an 'except' statement and not allow lists). The question was in relation as to whether it had something to do with a tuple's immutability.

Guido said it all had to do with a visual way of grouping tuples and nothing to do with what the underlying container was. If he had it to do over again he would rather change it so that except TypeError, ValueError: did the same thing as above. That change would alleviate the common error of expecting the above behavior using that syntax but instead getting the exception instance bound to ValueError. But the change is not planned for any time in the future since Guido has no proposal on how to change the syntax to handle the assignment to a local variable for the exception instance.

Contributing threads:

• Syntax for "except"

No, you can't subclass Bool

Francois Pinard discovered that you can't subclass the Bool type. This led to the question of "why?" To this he received the answer that since Bool only has two instance, True and False, it shouldn't be allowed to be a superclass of anything since that would suggest more instances of Bool could exist.

Contributing threads:

• bool does not want to be subclassed?

Function decoration and all that jazz

Bob Ippolito brought up Michael Hudson's function/method syntactic sugar to essentially implement PEP 318 (Michael's patch can be found at http://starship.python.net/crew/mwh/hacks/meth-syntax-sugar-3.diff) as something he really wanted for PyObjC.

In case you don't know what the syntax is def fxn() [fun, stuff, here]: pass, which ends up being the same as:

def fxn(): pass
fxn = here(stuff(fun(fxn)))

Common use cases are for defining class

The discussion then drifted in discussing how this syntax could even be used with classes and whether it could somehow supplant some metaclass uses. Talking seemed to lead to it not really being that great of a use case.

The order or application also came up. It was suggested that the order be the reversed of that shown above so that it reads the way it would be written by hand instead of in application order.

Using 'as' instead of brackets was brought up again; def fxn() as fun instead of def fxn() [fun]. An argument for this or any other syntax is that using brackets for this overloads the usage of them in Python itself and some feel that is unpythonic. An explicit argument for the brackets, though, is that it is cleaner for multi-line use. There was also the issue with using 'as' in terms of how would one look up its use in the docs? Would someone look up under 'as' or under 'def' naturally?

Contributing threads:

• Plea for function/method syntax sugar
• new syntax for wrapping
• PEP 318: What Java does
• other uses for "as"
• new syntax for wrapping (PEP 318) - Timothy's summary
• [UPDATED] PEP 318 - Function/Method Decorator Syntax

Building Python with the free .NET SDK

Go to the email to see Garth's latest tool and instructions on building Python using Microsoft's free .NET SDK.

Contributing threads:

• Compiling python with the free .NET SDK

PEP 326 finished (but still rejected)

PEP 326 ("A Case for Top and Bottom Values") has its final implementation linked from the PEP. It has been rejected (as with all PEPs that have been pronounced upon, read the PEP for the reasons why), but the PEP's authors will nice enough to go ahead and finish the code for anyone who might want to use it anyway.

Contributing threads:

• PEP 326

time.strftime() now checks its argument's bounds

Because of a possible crash from using negative values in the time tuple when passed to time.strftime(), it was decided to bound checks on all values in the time tuple. This will break existing code that naively set all fields to 0 in a passed-in time tuple and thus did not set the values within the proper bounds (year, month, day, and day of year should not be 0).

Contributing threads:

• Boundary checks on arguments to time.strftime()

OpenVMS throws a fit over universal newlines

For Python 2.4 the option to compile without universal newline support was removed. Well, it turns out that OpenVMS doesn't like this. Apparently the OS is not stream-oriented for its filesystem but is records-based and this leads to there being no newlines in a text file unless it is opened as a plain file.

Bug #903339 has been opened to deal with this.

Contributing threads:

• OpenVMS file system and UNIVERSAL_NEWLINES support

Forth-style argument passing for C functions

Raymond Hettinger came up with the idea of adding a new function flag called METH_STACK that would call a C function to be called with a pointer to the execution stack and the number of arguments it is being passed. This would allow the function to pop off its arguments on its own and bypass the expense of putting them into a tuple.

The overall idea did not seem to win out. But it does turn out that Michael Hudson has a patch that implements a similar idea at http://python.org/sf/876193 . A discussion of whether more specific argument passing like METH_O should be considered.

Contributing threads:

• Idea for a fast calling convention