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

[Raymond Hettinger]

On Apr 6, 2011, at 1:22 PM, Brett Cannon wrote:

> 
> 
> On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger <raymond.hettinger at gmail.com> wrote:
> 
> 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"?
> 
> 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.

Sounds good.

> 
> 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.

That seems reasonable for purely algorithmic modules.  I presume if an xz compressor gets added, there won't be a requirement that it be coded in Python ;-)

Also, I'm not sure the current wording of the PEP makes it clear that this is a going-forward requirement.  We don't want to set off an avalanche of new devs rewriting all the current C components (struct, math, cmath, bz2, defaultdict, arraymodule, sha1, mersenne twister, etc).

For the most part, I expect that people writing algorithmic C modules will start-off by writing a pure python version anyway, so this shouldn't be a big change to their development process.


> 
> 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. 
> 

Done!



Raymond

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110406/fa6543ee/attachment.html>