
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.

Armin Rigo <arigo@tunes.org> writes:
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?
What does he actually mean by (2)?
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).
Hmm. I wonder what memory consumption is like...
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 :-(
Boo :-(
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!
Sounds cool. Do you know how C++ specific it might be?
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!
Indeed! Cheers, mwh (who came as close to unsubscribing from python-dev as he's ever been today) -- Lisp nearing the age of 50 is the most modern language out there. GC, dynamic, reflective, the best OO model extant including GFs, procedural macros, and the only thing old-fashioned about it is that it is compiled and fast. -- Kenny Tilton, comp.lang.python

Michael Hudson wrote:
Armin Rigo <arigo@tunes.org> writes: ...
Let's prove him wrong!
Indeed!
Sure!
Cheers, mwh (who came as close to unsubscribing from python-dev as he's ever been today)
Because of decorators, so much growing iterator C implementations, optimization and growing featurism? -- Christian Tismer :^) <mailto:tismer@stackless.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

Christian Tismer <tismer@stackless.com> writes:
Cheers, mwh (who came as close to unsubscribing from python-dev as he's ever been today)
Because of decorators, so much growing iterator C implementations, optimization and growing featurism?
Not so much that (I'm the author of the decorators patch, after all) but long threads about changing something that has no chance of changing in a stupid way. Last week's climbing holiday meant two things: 1) fiddly details about programming languages don't seem that exciting right now, and 2) i read that big dumb thread in one sitting. Cheers, mwh -- Make this IDLE version 0.8. (We have to skip 0.7 because that was a CNRI release in a corner of the basement of a government building on a planet circling Aldebaran.) -- Guido Van Rossum, in a checkin comment

Michael Hudson wrote:
Not so much that (I'm the author of the decorators patch, after all)
Sure, it is just not ending.
but long threads about changing something that has no chance of changing in a stupid way.
Yup. py-dev is reaching the frequency of the main list, years ago. Time for a clean python-dev-dev list :) -- Christian Tismer :^) <mailto:tismer@stackless.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

On Mar 29, 2004, at 12:43 PM, Michael Hudson wrote:
Armin Rigo <arigo@tunes.org> writes:
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?
What does he actually mean by (2)?
Sandboxing arbitrary code is my guess (controlling its access to the filesystem, resource allocation, etc). Because, of course, doing it at the process boundary is probably too OS specific for something like chandler that has to run on windows. -bob
participants (4)
-
Armin Rigo
-
Bob Ippolito
-
Christian Tismer
-
Michael Hudson