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

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