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?
--
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/MIBXK7NM2C7MYQBXH7TZM7KREU2VXZZJ/
Code of Conduct: http://python.org/psf/codeofconduct/
