On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger wrote: Since people are taking my "semantically identical" point too strongly
for what I mean (there is a reason I said "except in cases
where implementation details of a VM prevents [semantic equivalency]
entirely"), how about we change the requirement that C acceleration code
must pass the same test suite (sans C specific issues such as refcount tests
or word size) and adhere to the documented semantics the same? It should get
us the same result without ruffling so many feathers. And if the other VMs
find an inconsistency they can add a proper test and then we fix the code
(as would be the case regardless). And in instances where it is simply not On Apr 6, 2011, at 10:39 AM, Brett Cannon wrote:
possible because of C limitations the test won't get written since the test
will never pass. Does the whole PEP just boil down to "if a test is C specific, it should be
marked as such"? How about the test suite needs to have 100% test coverage (or as close as
possible) on the pure Python version? That will guarantee that the C code
which passes that level of test detail is as semantically equivalent as
possible. It also allows the other VMs to write their own acceleration code
without falling into the same trap as CPython can.
There is also the part of the PEP strongly stating that any module that gets
added with no pure Python equivalent will be considered CPython-only and you
better have a damned good reason for it to be only in C from this point
forward. Anyone setting out to create equivalent code is already trying to making it
as functionally equivalent as possible. At some point, we should help
implementers by thinking out what kinds of implementation details are
guaranteed. I suspect 100% test coverage will be as good of a metric as any without
bogging ourselves down with every minute detail of C code that could change
as time goes on.
If we want a more thorough definition of what C code should be trying to do
to be as compatible with Python practices should be in a doc in the devguide
rather than this PEP. Raymond P.S. We also need a PEP 8 entry or somesuch giving specific advice about
rich comparisons (i.e. never just supply one ordering method, always
implement all six); otherwise, rich comparisons will be a never ending
source of headaches. Fine by me, but I will let you handle that one.