On Apr 6, 2011, at 1:22 PM, Brett Cannon wrote: > > > On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger <raymond.hettin...@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
_______________________________________________ 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
