(original) (raw)
On Thu, Feb 19, 2009 at 21:35, Steven D'Aprano <steve@pearwood.info> wrote:
As of right now there is no standard practice, although coming up with a standard way of handling this would probably be a good thing as this will also help with the testing story.
-Brett
Currently, if I want to verify that (say) cFoo and Foo do the same thing, or compare their speed, it's easy because I can import the modules separately. Given the 3.0 approach, how would one access the Python versions without black magic or hacks?Guido van Rossum wrote:
On Thu, Feb 19, 2009 at 8:38 PM, Brett Cannon <brett@python.org> wrote:
On Thu, Feb 19, 2009 at 19:41, Benjamin Peterson <benjamin@python.org>
wrote:
As we prepare to merge the io-c branch, the question has come up \[1\]Probably not a surprise, but +1 from me for keeping the pure Python version
about the original Python implementation. Should it just be deleted in
favor C version? The wish to maintain the two implementations together
has been raised on the basis that Python is easier to experiment on
and read (for other vm implementors).
around for the benefit of other VMs as well as a reference implementation.
You have been practice channeling me again, haven't you? I like the
idea of having two (closely matching) implementations very much. In
2.x we did this on an ad-hoc basis, e.g. \[c\]StringIO, pickle/cPickle,
heapq/\_heapq. In 3.0 we've moved towards standardizing the approach --
the foo.py file first defines everything and then tries to import \*
from \_foo on top of that.
As of right now there is no standard practice, although coming up with a standard way of handling this would probably be a good thing as this will also help with the testing story.
-Brett