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

Paul Moore p.f.moore at gmail.com
Mon Apr 18 10:36:20 CEST 2011


On 18 April 2011 08:05, Maciej Fijalkowski <fijall at gmail.com> wrote:
> On Sun, Apr 17, 2011 at 4:19 AM, Raymond Hettinger
> <raymond.hettinger at gmail.com> wrote:

>> Almost none of the concerns that have been raised has been addressed.  Does
>> the PEP only apply to purely algorithmic modules such as heapq or does it
>> apply to anything written in C (like an xz compressor or for example)?
>
> My understanding is it does apply only to stuff that does not wrap an
> external library.

My understanding is that this is most people's understanding, so it
should be explicitly documented in the PEP.

It would also be worth asking: are there any other reasons for using C
code beyond wrapping external libraries and accelerating code that
could equally be written in Python? I can't think of any, myself, but
OTOH I wonder if the *degree* of acceleration is also relevant - some
things (compression algorithms, for example) just can't realistically
be coded in Python (CPython, at least).

>> The PEP seems to be predicated on a notion that anything written in C is bad
>> and that all testing is good.
>
> Sounds about right

I disagree. To me, a Python without libraries such as os, zlib,
zipfile, threading, etc wouldn't be much use (except in specialised
circumstances). OK, that means that alternative implementations need
to do extra work to implement equivalents in their own low-level
language, but so be it (sorry!)

This PEP has a flavour to me of the old "100% pure Java" ideal, where
Java coders expected everything to be reimplemented in Java, avoiding
any native code. I didn't like the idea then, and I don't have much
more love for it now in Python. (OK, I know this is an exaggeration of
the position the PEP is taking, but without more clarity in the PEP's
language, I honestly don't know how much of an exaggeration).

Maybe the PEP could go through the various C libraries in the stdlib
at the moment, and discuss how the PEP would address them? It would be
useful to see how much of an impact the PEP would have had if it had
been Python policy from the start...

Paul.


More information about the Python-Dev mailing list