On Aug 1, 2019, at 09:27, Christopher Barker <pythonchb@gmail.com> wrote:

On Thu, Aug 1, 2019 at 9:19 AM Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:

> Given that in 3.x every stdlib module is supposed to be in Python with an optional C accelerator,

Is this written down somewhere? And when was that policy decided? 

PEP 399.

The PEP explicitly says that it only applies to new modules; the entire existing stdlib is grandfathered in:

This PEP does not mandate that pre-existing modules in the stdlib that lack a pure Python equivalent gain such a module. But if people do volunteer to provide and maintain a pure Python equivalent (e.g., the PyPy team volunteering their pure Python implementation of the csv module and maintaining it) then such code will be accepted. In those instances the C version is considered the reference implementation in terms of expected semantics.

So it’s certainly not mandatory to rewrite itertools in pure Python with a C accelerator, or even as a Python wrapper around C-only functions, if there’s no reason to do so.

But if there _is_ a reason to do so, the default seems to be that it would be accepted.

The benefit of copying some or all of the recipes into the module would still need to be sold before anyone agreed there actually is a good reason for the reimplementation. And of course the OP or someone else would have to volunteer to do the work. (Last I checked, PyPy doesn’t have a no-objspace version that could be borrowed.) But I don’t think it’s a non-starter the way it was in 2.6.

When we added math.is_close() (
https://www.python.org/dev/peps/pep-0485/) someone (Victor Stinner?) re-wrote the math module as a Python wrapper around the C one, so we could add pure Python functions to it. But that was rejected, and we stuck with pure C for that one.

I suspect math is a special case, in that it would presumably have received a special dispensation even if it were a brand-new module, since it mostly thinly wraps a C library (libm), and since a pure-Python implementation wouldn’t have been of any use to Jython or Iron or even PyPy. But, without reading the whole discussion in detail, it seems like the initial presumption was still that it was worth trying a Python wrapper, and it was only after that didn’t work out as well as hoped that it was rejected?