On Aug 2, 2019, at 11:55, Brendan Barnwell brenbarn@brenbarn.net wrote:
On 2019-08-02 10:11, Andrew Barnert wrote: Honestly, I think a lot of the resistance is the implementation issue, or at least it’s the reason the resistance is hard to overcome. If someone isn’t sure whether the benefit of having itertools.consume is worth the cost of implementing and maintaining it, the fact that the implementation would have to be in C pushes them hard in the no direction.
This is perhaps getting away from the main topic, but wait --- earlier in the thread someone said PEP 399 says all modules have to have a pure Python implementation. But now you say everything in itertools MUST be implemented in C? Why is that? Why can't we just put the Python implementations of the recipes as-is directly into itertools?
Because itertools is written purely in C, so there’s nowhere to put the Python implementations of the recipes.
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.