[Moving to python-ideas; python-dev to bcc] On Tue, Feb 2, 2010 at 2:02 AM, M.-A. Lemburg <m...@egenix.com> wrote: > Collin Winter wrote: [snip] >> If such a restrictive plugin-based scheme had been available when we >> began Unladen Swallow, I do not doubt that we would have ignored it >> entirely. I do not like the idea of artificially tying the hands of >> people trying to make CPython faster. I do not see any part of Unladen >> Swallow that would have been made easier by such a scheme. If >> anything, it would have made our project more difficult. > > I don't think that it has to be restrictive - much to the contrary, > it would provide a consistent API to those CPython internals and > also clarify the separation between the various parts. Something > which currently does not exist in CPython.
We do not need an API to CPython's internals: we are not interfacing with them, we are replacing and augmenting them. > Note that it may be easier for you (and others) to just take > CPython and patch it as necessary. However, this doesn't relieve > you from the needed maintenance - which, I presume, is one of the > reasons why you are suggesting to merge U-S back into CPython ;-) That is incorrect. In the year we have been working on Unladen Swallow, we have only updated our vendor branch of CPython 2.6 once, going from 2.6.1 to 2.6.4. We have occasionally cherrypicked patches from the 2.6 maintenance branch to fix specific problems. The maintenance required by upstream CPython changes has been effectively zero. We are seeking to merge with CPython for three reasons: 1) verify that python-dev is interested in this project, and that we are not wasting our time; 2) expose the codebase to a wider, more heterogenous testing environment; 3) accelerate development by having more hands on the code. Upstream maintenance requirements have had zero impact on our planning. In any case, I'll be interested in reading your PEP that outlines how the plugin interface should work, which systems will be pluggable, and exactly how Unladen Swallow, WPython and Stackless would benefit. Let's move further discussion of this to python-ideas until there's something more concrete here. The py3k-jit branch will live long enough that we could update it to work with a plugin system, assuming it is demonstrated to be beneficial. Thanks, Collin Winter _______________________________________________ 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
