text: .
  ..
  Quixote is another Web application framework. Its servlet lookup technique is very Pythonic: you place your servlet hierarchy in an importable Python package. Quixote processes the URL parts from left to right, using getattr() to find each part. This allows wide flexibility: each part can be a submodule, class, instance or anything else that has attributes. Eventually Quixote should find something callable: a function, a method or an instance with a .__call__ method. It calls that with a request data structure, and the return value is the HTML string (or an instance of a streaming class). At each step three special attributes in the parent affect the behavior:
  ._q_public (list of strings, required)
  Must list the subattribute. If the subattribute is missing or ._q_public is missing, Quixote pretends it couldn't find the subattribute. That's to prevent accidentally publishing private objects.
  ._q_access (function/method, optional)
  May raise AccessError to forbid the request.
  ._q_index (function/method, optional)
  Saves the day if Quixote falls off the end of the URL without finding something callable; akin to index.html.
  ._q_lookup (function/method, optional)
  Wildcard attribute if no specific attribute matches; akin to Python's .__getattr__().
  But the most interesting aspect of Quixote is its template system, PTL. It's useful not only in Web servlets but in a wide variety of applications. Unlike Nevow and most template systems that have placeholders in the text, PTL embeds the text as string literals in a function. For instance:
  # example.ptl def cell [html] (content): '<td>' content '</td>' def ordinary(): # An ordinary Python function. return "Result."
  To use it:
  import quixote; quixote.enable_ptl import example print example.cell("Acme & Co.") # Prints "<td>Acme & Co.</td>".
  enable_ptl installs an import hook, which tells import how to load *.ptl files, compile them and write *.ptlc files. [html] is a decorator as described in Guido's keynote above. Because Python doesn't yet have a decorator syntax built in, PTL has to fake it. The PTL compiler captures the literal result of each expression or string--what Python's interactive mode would have printed--and concatenates them into a return value. This is something I've often wished Python or Cheetah could do, and here it is. PTL seems more suited for templates with smallish blocks of text and a lot of calculations than for templates with multi-page static text and only a few placeholders.
  The [html] decorator automatically HTML-escapes expression results and arguments but does not escape literals. This is usually what you want, because results may come from an untrusted source, but literals are presumably correct. The return value is a pseudo string, an htmltext instance, used to protect it from further escaping should it be passed to another [html] function. There's also another decorator, [plain], which does all the concatenation goodies without the escaping and is suitable for your non-HTML applications.
  I went to the Atop talk because the summary said BSDDB. I thought, "Well, anything about Berkeley DB will be mildly interesting." It turned out to be majorly interesting, because Atop is an object database built on top of Berkeley DB. How did they know I recently had been looking for Python object databases besides ZODB?
  The session paper is not on-line, but the SubEthaEdit notes are. All serializable objects must subclass or be Item. Every item has a unique numeric ID; there's no physical nesting of objects. However, a Pool acts like a list and gives the illusion of nesting. In reality it contains pointers to the various raw items. Pools can be queried, for instance:
  pool = store.getItemByID(7) # 'store' is an open database. for item in pool.queryIndex('name', startKey='Bob'): # Loop through all elements whose 'name' attribute is >= 'Bob'. print item.name
  Berkeley DB is reliable, fast, easy to install and fully integrated with Python. Several other projects use it, including MySQL (as an optional table format) and Subversion. However, it's extremely difficult to use correctly, and the dangers include data corruption. Fortunately, Atop takes care of these problems so you don't have to.
  Atop currently is distributed as part of divmod.org's Quotient package, a Twisted server that's described next.
  The.
  The most entertaining talk was "Faster than C: Static Type Interface with Starkiller", by Michael Salib. That was only the fourth best title of the conference, however. The top three were "'Scripting Language' My Arse: Using Python for Voice over IP", by Anthony Baxter; "Flour and Water Make Bread", by David Ascher; and "Two Impromptus, or How Python Helped Us Design Our Kitchen", by Andrew Koenig.
  The Starkiller talk was enjoyable because Mike is one of two speakers who doesn't pull any punches--he calls a spade a shovel. His justification for writing a Python-to-C++ compiler was, "For the 15% of applications where speed matters, Python is slow. Sure, you can write it in C++, but C++ sucks. That's why we're using Python." Which actually makes a lot of sense if you think about it.
  He went on to explain how Python's dynamic features that we love so dearly is the reason Python is so hard to optimize. "Python has lots of runtime choice points, but thirty years of compiler optimization research depends on eliminating runtime choices." By "runtime choices" he's referring to the fact that a variable may change type, attributes may be added after startup and the like, and all this happens after a traditional optimizer would have finished and said sayonara. "But dynamic capability is good because Python kicks ass." So Starkiller follows the 80/20 rule by optimizing what it can and leaving the rest. In particular, it refuses to optimize functions that contain eval, exec or dynamic module loading. But that's okay because most users don't use them.
  Once those cases are eliminated, we examine the assignment statements to determine the types:
  x=3; y=x; z=y; z=4.3 # x is int. y is int. z is int or float.
  The types can be traced similarly through function arguments and return values. What about polymorphic functions? Starkiller handles them the same way C++ does: by generating distinct same-name functions for all argument combinations (aka overloading). Mike offers a few benchmarks to demonstrate the speed of this approach but also cautions, "All benchmarks are lies."
  If you want to play with Starkiller, you're out of luck because there's no public download yet. There actually were several talks this conference presenting software that's not yet available, either because it's not robust enough or it's waiting for legal paperwork. I didn't see that in previous conferences. A few attendees commented, "Well, it's not as useful as a talk on something that's available, but on the other hand it's good to learn about cutting-edge research as soon as possible." The conference reviewers seemed to have done their job of approving pre-alpha talks only if they covered an area that was central to Python and long on Python's wishlist. Mike had his own reason for not revealing the code. "If you kill me now, you'll never get it."
  Mike offered an obligatory acknowledgment. "Who owns Starkiller? MIT! Who paid for Starkiller's development? You did! Pat yourselves on the back! Thank you, taxpayers!!!" He then begs the audience not to tell DARPA that Starkiller is a Python-to-C++ converter rather than the sun-destroying weapon they think he's building. The presentation slides have a few more zingers too; they're available under the Session Papers link on the PyConDC2004 Aftermath link in Resources.
  Finally, Mike ended with an indictment of the."
  Guido had one question during Q&A. He asked, "Is it difficult to have so much attitude all the time?"
  (There's a discrepancy about when Guido asked that question. My notes say it was during this talk. The SubEthaEdit notes say it was during Anthony Baxter's VoIP talk, which was almost as feisty. But of course my notes are right.)
  Ah yes, that VoIP talk. Voice over IP may be Python's next killer application. Internet telephony currently is growing slowly, but it has the potential to become really big when it reaches critical mass. As VoIP becomes ubiquitous, people will need a new generation of applications and phones. Stoom, which runs under Twisted, is one small step in that direction. It needs a better UI, but it proves that Python is up to the task, even though VoIP requires generating sound packets exactly 20 milliseconds apart.
  By the way, the title of the VoIP paper is slightly modified from the original. It's currently "'Scripting Language' My Arse: Using Python for Voice over IP." Originally it was "'Scripting Language' My Shiny Metal Arse: Using Python for Voice over IP".
  Zope 3 hasn't changed much since last year; it's just further developed. It still aims to be friendlier to application developers than Zope 2, more Pythonic, more modularized, more specific in its API use (for example, less implicit acquisition), with better documentation early and a better integration of Web-based and filesystem-based application development methods. This will make applications more portable between Zope and other environments and make individual Zope features more accessible to non-Zope applications.
  The PyPy talk showed that a Python virtual machine can be written in 16,000 lines of Python. The prompt looks like this: >>>>, with one extra > for each recursive level of PyPy. PyPy is markedly slower than Python and exponentially slower recursively: the innermost interpreter interprets the code, the next interpreter interprets the interpreter interpreting the code. But the PyPy developers have faith that they eventually can make it faster than CPython.
  Pyrex stands alongside ctypes as an indispensable part of the C extension writer's toolkit. Pyrex compiles ordinary Python to C, but for better optimization you can use the cdef statement to declare variables as certain C types. Expressions using those variables are compiled directly to C, bypassing Python's slow object infrastructure.
  Several other talks are worth mentioning but I don't have the space. Browse the Session Papers link on PyConDC2004Aftermath site and see which topics night interest you.".