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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/XRLA2ICKKCCBY6YBXCQQDQEBYUEI2RXR/
Code of Conduct: http://python.org/psf/codeofconduct/
