PEP news

PEP 309 ("Partial Function Application") has been rewritten.

PEP 318 got a ton of discussion, to the point of warranting its own summary: PEP 318 and the discussion that will never end. PE 327, which is the spec for the Decimal module in the CVS sandbox, got an update.

Contributing threads:

• PEP 309 re-written
• Changes to PEP 327: Decimal data type

Playing willy-nilly with stack frames for speed

A patch to clean up the allocation and remove the freelist (stack frames not in use that could be used for something else) was proposed. Of course it would have been applied immediately if there wasn't a catch: recursive functions slowed down by around 20%.

A way to get around this was proposed, but it would clutter up the code which was being simplified in the first place. Guido said he would rather have that than have recursive calls take a hit.

Then a flurry of posts came about discussing other ways to try to speed up stack allocation.

Contributing threads:

• scary frame speed hacks
• reusing frames

PEP 318 and the discussion that will never end

Just looking at the number of contributing threads to this summary should give you an indication of how talked about this PEP became. In case you don't remember the discussion last time, this PEP covers function/method(/class?) decorators: having this:

def foo() [decorate, me]: pass

be equivalent to:

def foo(): pass
foo = me(decorate(foo))

What most of the discussion came down to was syntax and the order of application. As of this moment it has come down to either the syntax used above or putting the brackets between the function/method name and the parameters. Guido spoke up and said he liked the latter syntax (which is used by Quixote). People, though, pointed out that while the syntax works for a single argument, adding a long list starts to separate the parameter tuple farther and farther from the function/method name. There was at least one other syntax proposal but it was shot down quickly.

Order of application seems to have been settled. Some want the order to be like in the example. Others, though, want the reverse order: decorate(me(foo)). In the end, though, the order in the example code is what people preferred.

In the end it was agreed the PEP needed to be thoroughly rewritten which is currently happening.

Contributing threads:

• Pep 318 - new syntax for wrappers
• new syntax (esp for wrappers)
• PEP 318 - function/method/class decoration
• (Specific syntax of) PEP 318 - function/method/class
• PEP 318 - generality of list; restrictions on elements
• PEP 318 needs a rewrite
• Python-Dev Digest, Vol 8, Issue 20
• PEP 318 trial balloon (wrappers)
• funcdef grammar production

Compiler optimization flags for the core

The topic of compiler flags that are optimal for Python came up when Raymond Hettinger announced his new LIST_APPEND opcode (discussed later in Optimizing: Raymond Hettinger's personal crack). This stemmed from the fact that the bytecode has not been touched in a while. This generated a short discussion on the magic that is caches and how the eval loop always throws a fit when it gets played with. One suggestion was to rework some opcodes to use other opcodes instead in order to remove the original opcodes entirely from the eval loop. But it was pointed out it would be better to just factor out the C code to functions so that they are just brought into the cache less often instead of incurring the overhead of more loops through the eval loop.

This then led to AM Kuchling to state that he was planning in giving a lightning talk at PyCon about various compiler optimization flags he tried out on Python. Looks like that compiling Python/ceval.c with -Os (optimizes for space) w/ everything else using -O3 gave the best results using gcc 3. This sparked the idea of more architecture-dependent compiler optimizations which would be set when 'configure' was run and detected the hardware of the system.

In the end no code was changed in terms of the compiler optimizations.

Contributing threads:

• New opcode to simplifiy/speedup list comprehensions
• Who cares about the performance of these opcodes?

Take using Python as a calculator to a whole new level

I remember once there was a thread on comp.lang.python about how to tell when you had an addiction to Python. One of the points was when you start to use Python as your calculator (something I admit to openly; using the 'sum' built-in is wonderful for quick addition when I would have used a Scheme interpreter). Well, Raymond Hettinger had the idea of adding a 'calculator' module that would provide a ""pretty good" implementations of things found on low to mid-range calculators like my personal favorite, the hp32sII student scientific calculator". He then listed a bunch of functionality the HP calculator has that he would like to see as a module.

Beyond sparking some waxing about calculators, and the HP 32sII especially (I used a TI-82 back in high school and junior college so I won't even both summarizing the nostalgic daydreaming on HP calculators), the discussion focused mainly on what functionality to provide and the accuracy of the calculations. The former topic focused on what would be reasonable and relatively easy to implement without requiring a mathematician to write in order to be correct or fast.

The topic of accuracy, though, was not as clear-cut. First the issue of whether to use the in-development Decimal module would be the smart thing to do. The consensus was to use Decimal since floating-point, even with IEEE 754 in place, is not accurate enough for something that wants to be as accurate as an actual calculator. Then discussions on the precision of accuracy came up. It seemed like it would be important to have a level of precision kept above the expected output precision to make sure any rounding errors and such would be kept to a minimum.

Raymond is going to write a PEP outlining the module.

Contributing threads:

• calculator module

dateutil module proposed

Gustavo Niemeyer offered to integrate his dateutil module into the stdlib. Discussion of how it should tie into datetime and whether all of it or only some of its functionality should be brought in was transpired. As of right now the discussion is still going on.

Contributing threads:

• dateutil

Optimizing: Raymond Hettinger's personal crack

Raymond Hettinger, the speed nut that he is, added a new opcode to Python to speed up list comprehensions by around 35%. But his addiction didn't stop there.

Being the dealer of his own drug of choice, Raymond got his next fix by improving on iterations for dictionaries (this is, of course, after all of his work on the list internals). As always, thanks goes to Raymond for putting in the work to make sure the CPython interpreter beats the Parrot interpreter by that much more come OSCON 2004 and the Pie-thon contest.

And, at Hye-Shik Chang's request, Raymond listed off his list of things to do to feed his addiction so he doesn't go into withdrawls any time in the future. Most of them are nice and involved that would make great personal/research projects.

Contributing threads:

• New opcode to simplifiy/speedup list comprehensions
• Joys of Optimization