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

[Brett Cannon]

On Sat, Apr 16, 2011 at 14:23, Stefan Krah <stefan at bytereef.org> wrote:

> Brett Cannon <brett at python.org> wrote:
> > In the grand python-dev tradition of "silence means acceptance", I
> consider
> > this PEP finalized and implicitly accepted.
>
> I did not really see an answer to these concerns:
>
> http://mail.python.org/pipermail/python-dev/2011-April/110672.html
>

Antoine does seem sold on the 100% branch coverage requirement and views it
as pointless. I disagree. =)

As for the exception Stefan is saying may be granted, that is not in the PEP
so I consider it unimportant. If we really feel the desire to grant an
exception we can (since we can break any of our own rules that we
collectively choose to), but I'm assuming we won't.


> http://mail.python.org/pipermail/python-dev/2011-April/110675.html
>

Raymond thinks that have a testing requirement conflates having
implementations match vs. APIs. Well, as we all know, the stdlib ends up
having its implementation details relied upon constantly by people whether
they mean to or not,  so making sure that this is properly tested helps deal
with this known reality.

This is a damned-if-you-do-damned-if-you-don't situation. The first draft of
this PEP said to be "semantically equivalent w/ divergence where technically
required", but I got pushback from being too wishy-washy w/ lack of concrete
details. So I introduce a concrete metric that some are accusing of being
inaccurate for the goals of the PEP. I'm screwed or I'm screwed. =) So I am
choosing to go with the one that has a side benefit of also increasing test
coverage.

Now if people would actually support simply not accepting any more C modules
into the Python stdlib (this does not apply to CPython's stdlib), then I'm
all for that. I only went with the "accelerator modules are okay" route to
help get acceptance for the PEP. But if people are willing to go down a more
stringent route and say that any module which uses new C code is considered
CPython-specific and thus any acceptance of such modules will be damn hard
to accomplish as it will marginalize the value of the code, that's fine by
me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110416/f8998e0f/attachment.html>