[pypy-dev] Re: PyCON bits

[Michael Hudson]

Armin Rigo <arigo at 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