Improvements to the Python core (was: Is a "real" C-Python possible?)

[Paul Boddie]

On 12 Des, 18:58, Christian Heimes <li... at cheimes.de> wrote:
>
> I don't see an indication that anybody but the creator of Psyco does
> understand the code base. *g*

Then you haven't been reading the right IRC channel recently. ;-)

> Guido has stated his opinion about optimizations more than once. My own
> opinion as core developer (which is quite similar to Guido's opinion) is:
>
> We are happy and glad for every improvement regarding speed, memory
> usage or features if and only if:
>
>  * The implementation must be clean, well designed, well documented well
> written and platform independent / supported on all platforms. Python
> runs on machines from mobile phones to large main frames.

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.

>  * The improvement must NOT hinder or slow down future development at
> all cost. If it's so complicated that it might slow down future
> development than it's a no go. It's more important to us to have a clean
> and understandable code base than to add hundreds of small improvements
> which makes debugging a nightmare.

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

>  * You are willing to support and fix the improvement for X years where
> X is between 4 and INF years.

Can't argue with this one. ;-)

>  * The modification must not slow down Python for common uses like a
> single threaded, single CPU bound program or small script. This rules
> out all existing attempts to remove the GIL from Python since they have
> slowed down Python to 50% or less. However Guido said a few months ago
> that he would endorse a SMP branch of Python aimed to multi core and
> multi threaded apps.

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.

Paul