Collin Winter wrote: > On Mon, Feb 1, 2010 at 11:17 AM, M.-A. Lemburg <m...@egenix.com> wrote: >> Collin Winter wrote: >>> I think this idea underestimates a) how deeply the current CPython VM >>> is intertwined with the rest of the implementation, and b) the nature >>> of the changes required by these separate VMs. For example, Unladen >>> Swallow adds fields to the C-level structs for dicts, code objects and >>> frame objects; how would those changes be pluggable? Stackless >>> requires so many modifications that it is effectively a fork; how >>> would those changes be pluggable? >> >> They wouldn't be pluggable. Such changes would have to be made >> in a more general way in order to serve more than just one VM. > > I believe these VMs would have little overlap. I cannot imagine that > Unladen Swallow's needs have much in common with Stackless's, or with > those of a hypothetical register machine to replace the current stack > machine. > > Let's consider that last example in more detail: a register machine > would require completely different bytecode. This would require > replacing the bytecode compiler, the peephole optimizer, and the > bytecode eval loop. The frame object would need to be changed to hold > the registers and a new blockstack design; the code object would have > to potentially hold a new bytecode layout. > > I suppose making all this pluggable would be possible, but I don't see > the point. This kind of experimentation is ideal for a branch: go off, > test your idea, report your findings, merge back. Let the branch be > long-lived, if need be. The Mercurial migration will make all this > easier. > >> Getting the right would certainly require a major effort, but it >> would also reduce the need to have several branches of C-based >> Python implementations. > > 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. 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 ;-) The same problem exists for all other branches, such as e.g. Stackless. Now, why should we merge in your particular branch and make it harder for those other teams ? Instead of having 2-3 teams maintain complete branches, it would be more efficient to just have them take care of their particular VM implementation. Furthermore, we wouldn't need to decide which VM variant to merge into the core, since all of them would be equally usable. The idea is based on a big picture perspective and focuses on long term benefits for more than just one team of VM implementers. BTW: I also doubt that Mercurial will make any of this easier. It makes creating branches easier for non-committers, but the problem of having to maintain the branches remains. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 02 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ 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
