[Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Wed Apr 6 23:40:41 CEST 2011
- Previous message: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements
- Next message: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Apr 7, 2011 at 6:22 AM, Brett Cannon <brett at python.org> wrote:
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.
Independent of coverage numbers, C acceleration code should really be tested with 3 kinds of arguments:
- builtin types
- subclasses of builtin types
- duck types
Those are (often) 2 or 3 different code paths in accelerated C code, but will usually be a single path in the Python code.
(e.g. I'd be willing to bet that it is possible to get the Python version of heapq to 100% coverage without testing the second two cases, since the Python code doesn't special-case list in any way)
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements
- Next message: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]