Rationale for Conditional Expression

Guido explained part of his rationale for adding a conditional expression to Python 2.5. Many users have been attracted to the subtly flawed "a and b or c" form. (It returns c if a is True and b evaluates to False.) Adding a direct form will prevent bugs in their code.

I still don't like it. The proposed form "val if test else val" is too confusing. The test does not belong in the middle. The right thing is "if test then value else val," which Guido is not doing because of the cost of introducing a "then" keyword. (It is also excruciating to get the parser to recognize the difference between a bare "if ... then ..." expression and an "if ...:" statement.)

Exposing AST to Python Programs

Yesterday we decided to expose the AST as a set of Python objects, one class for each constructor in the AST with abstract base classes for each type. Martin von Löwis checked it in today! The code recursively copies the internal C representation to Python objects.

Python Compiler Sessions

We had a birds of a feather (BOF) session about the new Python bytecode compiler. We had a large crowd -- as many as 50 people. The discussion was open-ended and we didn't make many specific decisions.

One result was to come up with a list of tasks that should be completed to make the AST useful for Python programmers:

• We need generic API to child nodes in AST. This ai would have a function to get all the child nodes. The current API exposes only named attributes for specific children.
• It would be great if the AST could be used in conjunction with tools that do source-to-source transformations. This use requires an association between the AST and raw tokens (and comments, too). John Ehresman suggested adding a token range as an annotation on the AST.
• Users who tried the old compiler package found that tree walking pure Python was too slow. We should write a generic walker in C that can be extended with Python functions to call for specific nodes, presumably with pre-order, post-order, and in-order traversals. Performance is important in practice.

We collected several concrete use cases for the AST. People who attended the BOF wanted to:

• Restrict the scope of Python programs, along the lines of the compiler for Zope's "Python Scripts"
• Parsing source to generate documentation.
• Generate SQL, Verilog statements from Python code. Generally, I think, things along the lines of LINQ.
• Optimizers
• Branch coverage analysis

The compiler package has always been hard to maintain. In principle, I like having a pure Python compiler. In practice, it is tiresome to maintain two different compilers when one is used infrequently. Several key problems for the 2.5 release are:

• The AST is uses is different than the builtin AST.
• There are bugs in the 2.4 implementation, particularly in namespace resolution. (Why didn't someone assign the bug to me?)
• The compiler package doesn't have a good test suite.

There was some question about whether to label the compiler package as experimental or deprecated, but we did not decide.

Earlier in the morning, I gave a talk on the new bytecode compiler -- a whirlwind tour intended to help new developers get up to speed. I hadn't prepared adequately, so I went through some of the material too quickly. I got a number of good questoins. Brett and Steve suggest it went pretty well.

Exquisite Timing

I got up early this morning to write my slides for the bytecode talk. I didn't get down to the conference this morning until Guido's keynote was well underway. When I walked into the ballroom, the slide about the AST code was on the projector and Guido was saying something about the speed of the new compiler. The very next moment Guido asked me whether it was faster -- as if it were scripted.

The compiler actually is faster, but not by much. We made no effort to make the compiler faster. I just wanted the code to be simple and easy to maintain. There are some obvious optimizations available. Changing the ast to use a real arena implementation should speed up memory allocation. Doing peephole optimizations before the assembler runs should speed it up. Maybe using the arena for the parser would help, too. Changing pgen to generate the AST directly and avoid the hand-coded transformations in ast.c should be a win, but won't get done for Python 2.5.

Python Ain't Got No Wrong Notes

Django is named after Django Reinhardt. It aspires to be sublime. There is a CMS for newspapers built on top of Django called Ellington. I think the next project should be called Thelonius. (I'd say Monk, but it doesn't have the same mystique). The perfect tag line would be "Python ain't got no wrong notes."

Source: I heard a great radio interview with Phil Schaap where he recounted a story about Monk. I found it repeated on the WKCR web site:

March of '76 was Thelonious Monk. There was a guy on the air doing that standard gibberish about Monk: "and Monk, playing the wrong notes on the piano, is able to create this kind of music....". Anyway, Monk called the Columbia switchboard, and the Columbia switchboard got in touch with me and said that Thelonious Monk had called to say that we should tell the guy on the air, "The piano ain't got no wrong notes."

Tracking PyCon in the Blogosphere

I expect lots of bloggers will write about PyCon. Googlers will be posting to the PyCon blog again, and Planet Python should have plenty of material. I also subscribed to a pycon query in Google BlogSearch with my feed reader (modest plug).

Dallas Travel Tips

NY Times advice on Going to Dallas. Most of the advice is about locations around the downtown area, a good 10-12 miles from Addison and PyCon. No car for me, so it's unlikely I'll see much.