On Thu, Mar 26, 2009 at 8:05 PM, Terry Reedy <tjre...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
