Armin Rigo <[EMAIL PROTECTED]> 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 _______________________________________________ [EMAIL PROTECTED] http://codespeak.net/mailman/listinfo/pypy-dev
