Hello! As promized, here are a few bits of news from PyCON... This isn't a complete report (there are blogs out there for that). It's just a few PyPy-oriented notes. The sprints: I participated in the Python Core sprint. There was some lack of a concrete objective, Guido and Tim Peters didn't show up a lot (I know Guido was ill). So people just formed loose groups, changing over the days, doing a wide range of small stuff. I did a few bits on performance in CPython and some core stuff, mostly with Martin von Loewis, who embarked on the cruisade against start-up time. Mitchell Kapor's keynote (Using Python to Develop a Large-Scale Open Source Application: A Report from the Field): the two main points stressed by Mitchell is that Python needs (1) more performance and (2) more security. Looks familiar? IronPython (Jim Hugunin): Python for .NET. Seems to be very fast, up to 40% better than CPython. The trick is to contrieve as much as possible (and more!) the Python semantics so that they fit into existing .NET built-in operations. .NET itself is then able to optimize them extremely agressively. The result is generally significantly faster than CPython. What we could learn from IronPython is how the common cases are speeded up by a lot of boilerplate "fast-path" code (i.e. there is a 8x8 table for calling a function with 0 to 7 arguments when the function expects 0 to 7 arguments). The other thing we could learn is how to use .NET as a PyPy target platform, what the tricks and the main limitations are. But Jim doesn't release code before he thinks it is finished :-( Starkiller (Michael Salib): this is a purely static source-to-source Python-to-C++ translator, which does type inference. It works by analysing a graph which closely mirrors the Python source code. As expected, it has some trouble with the most dynamic features like exec/eval, but it is relatively advanced in some directions like OO. Some control structures (like 'for') are not implemented. Bob Ippolito came up with an incredibly cool idea: we can already generate control flow graphs, which give a low-level pre-processed version of a Python source; so we should just feed that into Starkiller, which would analyse it and translate it into C++. Starkiller shouldn't try to parse the source and analyse at the source syntax level -- we can do better with the control flow graphs. But we shouldn't try to reimplement type inference -- Starkiller does a better job at that. Starkiller is precisely the component we are missing in our translation project! Starkiller isn't released yet, as far as I know. I'll talk to Michael about it. Hopefully we can get the core of Starkiller under a non-GPL license (some old web pages from 2001 talk about an upcoming GPL release of Starkiller). Bob Ippolito talked about attending the PyPy sprint at EuroPython. (He was at the Stackless sprint.) We should talk to Michael as well. Guido's keynote (Python 3000): some directions for the next major rewrite of Python. I have a rant against both issues in the language evolution that he talked about: a syntax for types, and much more iterators. As far as I can see, both are essentially a way to improve the performance and reduce the simplicity of the language. I'm ok with performance tricks that don't show up on the user, but not with the ones that require him to learn new ways of getting the job done when there is already one. Particularly when we have the theory to recover most of that performance automatically. """Q: Will python 3k be built in python? A: Ask Armin (Rigo) and Laura (Creighton). If they succeed it's possible for Pypy to be the base for Python 3K. Guido thinks it's about as likely as Python 3K being written on top of Parrot...""" Let's prove him wrong! A bientot, Armin.