On 2019-08-02 19:16, Andrew Barnert wrote:
PEP 399 says all _new_ modules (that don’t have a good reason for a special dispensation) have to have a pure Python implementation. But it explicitly says that pre-existing modules in the stdlib didn’t need to be rewritten, and most of them haven’t been. (Raymond wrote itertools long before 3.2, even long before the discussion around 3.0 that eventually led to the PEP.) It also says that if someone like the PyPy developers wants to rewrite an existing C module to be a pure-Python module with a C accelerator it should/will probably be accepted, but that only applies if someone does the rewrite and submits it.
So, that’s the way forward. You could port the recipes to C and change the docs recipes to be “roughly equivalent” Python code in the help for each function. Or you could port itertools to Python plus C accelerator and then just copy-paste the recipes into the Python part. I suspect the latter would be easier to get accepted, but I have no idea whether it’s more or less work.
Does "port itertools to Python plus C accelerator" include "write a thin Python wrapper around the existing C"? That is, would it be possible to write a pure-Python wrapper around the existing C itertools (renaming that existing C module to _itertools or whatever), and add the recipes as pure Python in the wrapper but without a C implementation? Or would that not be accepted? -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown