[Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements (original) (raw)

Raymond Hettinger raymond.hettinger at gmail.com
Sun Apr 17 09:30:22 CEST 2011

In the grand python-dev tradition of "silence means acceptance", I consider this PEP finalized and implicitly accepted. I haven't seen any responses that said, yes this is a well thought-out proposal that will actually benefit any of the various implementations. In that case it may well be that the silence is because the other implementations think the PEP is OK. They certainly voted in favor of the broad outline of it at the language summit.

Sounds like it was implicitly accepted even before it was written or any of the details were discussed.

The big picture of "let's do something to make life easier for other implementations" is a worthy goal. What that something should be is still a bit ambiguous.

every branch in a given implementation now guarantee every implementation detail or do we only promise the published API (historically, we've always done the latter)? As Brett said, people do come to depend on the details of the implementation. But IMO the PEP should be clarified to say that the tests we are talking about should be tests of the published API. That is, blackbox tests, not whitebox tests.

+1 That's an excellent suggestion. Without that change, it seems like the PEP is overreaching.

Is there going to be any guidance on the commonly encountered semantic differences between C modules and their Python counterparts (thread-safety, argument handling, tracebacks, all possible exceptions, monkey-patchable pure python classes versus hard-wired C types etc)? Presumably we will need to develop such guidance.

+1 That would be very helpful. Right now, the PEP doesn't address any of the commonly encountered differences.

I personally have no problem with the 100% coverage being made a recommendation in the PEP rather than a requirement. It sounds like that might be acceptable to Antoine. Actually, I would also be fine with saying "comprehensive" instead, with a note that 100% branch coverage is a good way to head toward that goal, since a comprehensive test suite should contain more tests than the minimum set needed to get to 100% branch coverage.

+1 better test coverage is always a good thing (IMO).

Raymond

More information about the Python-Dev mailing list