Towards faster Python implementations - theory

John Nagle nagle at animats.com
Fri May 11 12:04:35 EDT 2007


Tim Golden wrote:
> sturlamolden wrote:
> 
>> On May 8, 5:53 pm, John Nagle <n... at animats.com> wrote:
>>
>>>     The point here is that we don't need language changes or 
>>> declarations
>>> to make Python much faster.  All we need are a few restrictions that
>>> insure that, when you're doing something unusual, the compiler can
>>> tell. 
> 
> I doubt if anyone disputes the gist of what you're
> saying[*], viz that Python could be made faster by using
> technique (a), (b) or (c) which have been successful elsewhere. At least 
> that it's worth investgating.
> 
> But the relevant bit of your last paragraph is at the start:
> "We should...". Unless someone or someones has the time,
> inclination, money, backing, wherewithal etc. to implement
> this or any other measure of speeding-up, it's all
> pie-in-the-sky. Useful, maybe, as discussion of what
> options are viable, but a project of this magnitude
> doesn't just happen in some developer's lunchbreak.

     Focusing may help.  Between Jython, PyPy, and Shed Skin,
enough effort has been put in to produce something better than
CPython, but none of those efforts resulted in something more
useable than CPython.

     There's a "commercial grade Python" from ActiveState, but
that's CPython in a cardboard box, I think.

     Another problem is that if the language is defined as
"whatever gets put in CPython", that discourages other
implementations.  The language needs to be standards-based.

				John Nagle



More information about the Python-list mailing list