On Apr 13, 2011, at 4:52 AM, Antoine Pitrou wrote:
On Wed, 13 Apr 2011 06:28:58 +0200 Stefan Behnel
wrote: However, I think we are really discussing a theoretical issue here. All the PEP is trying to achieve is to raise the bar for C code in the stdlib, for exactly the reason that it can easily introduce subtle semantic differences in comparison to generic Python code.
True. But then we're much better without a formal requirement that some people will start trying to require because they don't understand that its metric is pointless.
I concur. For most part, anyone converting from C-to-Python or Python-to-C is already doing their best to make the two as similar as they can. The PEP falls short because its coverage metric conflates the published API with its implementation details. The PEP seems confused about the role of white box testing versus black box testing. Nor does the PEP provide useful guidance to anyone working on a non-trivial conversion such as decimal, OrderedDict, or threading. If the underlying theme is "nothing written in C is good for PyPy", perhaps the PEP should address whether we want any new C modules at all. That would be better than setting a formal requirement that doesn't address any of the realities of building two versions of a module and keeping them in sync. Raymond