[pypy-dev] PyCON bits
arigo at tunes.org
Mon Mar 29 19:18:11 CEST 2004
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
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.
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
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!
More information about the Pypy-dev