RetroSearch Browse

Wed Apr 6 23:40:41 CEST 2011 · https://mail.python.org/pipermail/python-dev/2011-April/110515.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-April/110515.html below:

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