On Dec 8, 2019, at 22:01, Tim Peters <tim.pet...@gmail.com> wrote: > > BTW, another change I'd make is to break the tradition of coding every > itertools function in C. That makes the implementation bar much > higher, and the other similar packages (more_itertools, > toolz.itertools) don't bother. There's also that pypy has trouble > optimizing code using itertools heavily, _because_ it's written in C > instead of Python.
Didn’t PyPy already make the fix years ago of rewriting all of itertools (for both 2.7 and 3.3 or whenever) as “Python builtins” in the underlying namespace? Also, even if I’m remembering wrong, just writing a Python module in front of the C module, with most of the functions still being C-only, wouldn’t help PyPy. You’d still need to port every function to Python (and be aware that the “equivalent code” in the help is usually only a rough equivalent with subtle differences, so you’d have to spot, fix, and write unit tests for all of those), with the C only an optional accelerator, a la PEP 399 (the requirements for C accelerators in newly-added modules). Which is far from impossible, it’s just more work than it seems like anyone’s ever been willing to do each time it comes up (and you’re right, it comes up every time a new potentially useful itertools tool is proposed…). If someone cares about first enough to finally do that, I’m +1 on the proposal instead of 0. _______________________________________________ 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/UR63YBE7PHDQ3ZYVXJQTXUACYQVPOWTY/ Code of Conduct: http://python.org/psf/codeofconduct/
