2010/1/20 Collin Winter <collinwin...@google.com>: > Hello python-dev, > > I've just committed the initial draft of PEP 3146, proposing to merge > Unladen Swallow into CPython's source tree and roadmap. The initial > draft is included below. I've also uploaded the PEP to Rietveld at > http://codereview.appspot.com/186247, where individual fine-grained > updates will be tracked. Feel free to comment either in this thread or > on the Rietveld issue. I'll post periodic summaries of the > discussion-to-date. > > We're looking forward to discussing this with everyone.
I'll comment on a number of points here - I've read the thread but it'd get too complex trying to quote specific items. First of all, I'm generally in favour of this. While I don't have any problems with Python's speed, I still think performance improvements are a good thing, and the fact that Unladen Swallow opens up a whole new range of possibilities, above and beyond any immediate performance gains, means that Python should end up with a healthy change of ongoing performance improvements. I'm concerned about the memory and startup time penalties. It's nice that you're working on them - I'd like to see them remain a priority. Ultimately a *lot* of people use Python for short-running transient commands (not just adhoc scripts, think "hg log") and startup time and memory penalties can really hurt there. Windows compatibility is a big deal to me. And IMHO, it's a great strength of Python at the moment that it has solid Windows support. I would be strongly *against* this PEP if it was going to be Unix or Linux only. As it is, I have concerns that Windows could suffer from the common "none of the developers use Windows, but we do our best" problem. I'm hoping that having U-S integrated into the core will mean that there will be more Windows developers able to contribute and alleviate that problem. One question - once Unladen Swallow is integrated, will Google's support (in terms of dedicated developer time) remain? If not, I'd rather see more of the potential gains realised before integration, as otherwise it could be a long time before it happens. Ideally, I'd like to see a commitment from Google - otherwise the cynic in me is inclined to say "no" until the suggested speed benefits have materialised and only then accept U-S for integration. Less cynically, it's clear that there's quite a way to go before the key advertised benefits of U-S are achieved, and I don't want the project to lose steam before it gets there. I suppose as far as the goals in the PEP go: > - Approval for the overall concept of adding a just-in-time compiler to > CPython, > following the design laid out below. +1 > - Permission to continue working on the just-in-time compiler in the CPython > source tree. +1 > - Permission to eventually merge the just-in-time compiler into the ``py3k`` > branch once all blocking issues have been addressed. Provisionally +1, subject to clarification on "eventually". I'd rather that not only "blocking issues" be addressed, but also some (not minimal) level of performance gain be achieved. > - A pony. I'll leave that to Guido :-) Paul. _______________________________________________ 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
