[Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

Raymond Hettinger raymond.hettinger at gmail.com
Wed Apr 6 21:45:25 CEST 2011


On Apr 6, 2011, at 10:39 AM, Brett Cannon 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 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"?

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.


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.


More information about the Python-Dev mailing list