[Python-Dev] peps: Update PEP 399 to include comments from python-dev. (original) (raw)
R. David Murray rdmurray at bitdance.com
Wed Apr 13 19:00:40 CEST 2011
- Previous message: [Python-Dev] peps: Update PEP 399 to include comments from python-dev.
- Next message: [Python-Dev] peps: Update PEP 399 to include comments from python-dev.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Antoine Pitrou, 13.04.2011 02:07:
On Tue, 12 Apr 2011 19:50:34 -0400 Tres Seaver wrote:
Trying to accelerate existing code which doesn't have the coverage is insane: how can you know that the accelerator doesn't subtly change the semantics without tests? Well, why do you think tests guarantee that the semantics are the same? Tests are not a magic bullet. "Covering" a code path doesn't ensure that every possible behaviour is accounted for.
When I suggested we add 100% branch coverage as a recommendation or requirement to the PEP, I pointed out that it was a place to start. Nobody is saying it guarantees the semantics are the same, that was the whole point of replacing the statement about semantics with the statement about test coverage. When we find places where the two versions don't match, we will have to (a) decide the compatibility issue[*] and (b) add tests that enshrine the decision.
As Tres said, if I were writing an accelerator, I'd want to start with 100% branch coverage just to have as good as practical a check on my implementation as I could. I'd also try to think of additional tests.
I'm doing this in email (increasing test coverage to 100% before rewriting algorithms) even though I'm not doing C accelerators. It just seems like the sensible thing to do. (You may think I'm really crazy, since some of the tests needed to get to 100% branch coverage will be testing lines of code that I'm removing....but those tests represent particular edges cases and I want to know that those edge cases continue to pass after I change the code.)
[*] Maybe the PEP needs to talk about the basis on which those decisions will be made: maintaining compatibility across Python implementations. In other words, a CPython C accelerator can be viewed as breaking compatibility with standard Python if it doesn't implement the documented interface of the Python version of the module. (My apologies if this is in fact already discussed, I didn't reread the PEP to check.) The idea is to use the test suite as the check for this, adding tests as necessary.
-- R. David Murray http://www.bitdance.com
- Previous message: [Python-Dev] peps: Update PEP 399 to include comments from python-dev.
- Next message: [Python-Dev] peps: Update PEP 399 to include comments from python-dev.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]