Improvements to the Python core

[Christian Heimes]

Paul Boddie wrote:
> Then you haven't been reading the right IRC channel recently. ;-)

What's the right channel? I'm on #python and #python-dev

> Indeed, but there's arguably a certain amount of deadlock around
> making unpatched, released versions of Python available in all these
> places, unless there's been some activity below the surface in the
> python-dev community on things like cross-compilation and not running
> distutils using the newly built Python executable (which, as I
> remember, was but one of the problems). Your point stands, naturally,
> but if there's potential for some real movement on some
> uncontroversial issues, and yet we see no movement, one remains
> skeptical about getting even slightly controversial improvements into
> vanilla CPython.

I don't get your point, especially when you talk about distutils. Please
elaborate.

(C)Python has a well known process to get new features or changes into
the language: Write a PEP, convince enough core developers and/or Guido,
implement the feature. I don't see a PEP about JIT in the list at
abouthttp://www.python.org/dev/peps/, do you? :]

Besides nobody is going to stop you from creating a fork. Christian
Tismer forked of stackless years ago. It's a successful branch with
useful additions to the language. It got never merged back because
Christian didn't feel right about it.

> Perhaps, but what would people prefer: yet more language bolt-ons or
> better performance?

I prefer a fast, stable and maintainable Python over a faster but unstable.

> It will be interesting to see what happens with recent work on
> improving threading within CPython. As for Psyco (which perhaps offers
> concurrency benefits only through instruction-level parallelism, if we
> briefly consider that topic), I can understand that just-in-time
> compilation can bring certain penalties in terms of memory usage and
> initialisation times (as Java virtual machines have demonstrated), but
> there's a compelling argument for trying to make such technologies
> available to CPython if they can be switched off and won't then incur
> such penalties. But we presumably return to the point of people not
> wanting to touch code that has anything to do with such features: a
> combination of social factors and the priorities of the group.

Rhamph is working on a GIL-less Python version. It may become a compile
time option someday in the future. Others have worked hard to speed up
other parts of Python. We have multiple pending patches which speed up
small parts of Python. Some are related to peephole (byte code
optimizations), other patches speed up attribute access on classes or
globals. The global lookup patch makes globals as fast as locals.

I've done my share for the poor Windows souls when I created the VS 2008
PCbuild9 directory and enabled PGO builds. PGO builds are about 10%
faster than ordinary VS 2008 builds. VS 2008 should be slightly faster
than VS 2003 but I can bench mark it on my machine.

In my opinion an optional JIT as compile time or startup option has good
chances to become part of the CPython implementation. You "only" have to
replace ceval.c ... :]

Christian