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. Especially since consume is at least as important as sample code as usable code, so you’d still need to maintain the pure Python “equivalent” in the docs, as with most of the core itertools functions. (And notice that, unlike a Python module with optional C accelerator; a C module with Python equivalent in the docs can’t easily be unit tested to verify that equivalence—and many itertools functions would fail, which is why the docs say “roughly equivalent”.)
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?