[Python-Dev] GPython?

[Collin Winter]

On Thu, Mar 26, 2009 at 8:05 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> An ars technica articla just linked to in a python-list post
>
> http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-boost-python-performance-by-5x.ars
>
> calls the following project "Google launched"
> http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
>
> (Though the project page does not really claim that.)

Hi, I'm the tech lead for Unladen Swallow. Jeffrey Yasskin and Thomas
Wouters are also working on this project.

Unladen Swallow is Google-sponsored, but not Google-owned. This is an
open-source branch that we're working on, focused on performance, and
we want to move all of our work upstream as quickly as possible. In
fact, right now I'm adding a last few tests before putting our cPickle
patches up on the tracker for further review.

> I am sure some people here might find this interesting.
>
> I'd love to have a faster CPython, but this note:
> "Will probably kill Python Windows support (for now)."
> would kill merger back into mainline (for now) without one opposing being
> 'conservative'.

To clarify, when I wrote 'conservative', I wasn't being disparaging. A
resistance to change can certainly be a good thing, and something that
I think is very healthy in these situations. We certainly have to
prove ourselves, especially given some of the fairly radical things
we're thinking of [1]. We believe we can justify these changes, but I
*do* want to be forced to justify them publicly; I don't think
python-dev would be doing its job if some of these things were merely
accepted without discussion.

In particular, Windows support is one of those things we'll need to
address on our end. LLVM's Windows support may be spotty, or there may
be other Windows issues we inadvertently introduce. None of the three
of us have Windows machines, nor do we particularly want to acquire
them :), and Windows support isn't going to be a big priority. If we
find that some of our patches have Windows issues, we will certainly
fix those before proposing their inclusion in CPython.

> If one adds type annotations so that values can be unboxed, would not
> Cython, etc, do even better for speedup?

Possibly, but we want to see how far we can push the current language
before we even start thinking of tinkering with the language spec.
Assigning meaning to function annotations is something that PEP 3107
explicitly avoids, and I'm not sure Unladen Swallow (or anyone else)
would want to take the plunge into coming up with broadly-acceptable
type systems for Python. That would be a bikeshed discussion of such
magnitude, you'd have to invent new colors to paint the thing.

Collin Winter

[1] - http://code.google.com/p/unladen-swallow/wiki/ProjectPlan