On Mon, Dec 9, 2019 at 10:03 AM Tim Peters <tim.peters@gmail.com> wrote:
[Andrew Barnert <abarnert@yahoo.com>]
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?
I don't know.
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.
I wasn't suggesting that. I was suggesting that we drop the tradition of writing _every_ itertools function in C and _only_ C. That would lower the bar for adding new functions. Many of the many functions in the more_itertools and toolz.itertools packages are implemented by brief pure Python functions, often just 1-liners. Works fine for them.
Plus you have to start somewhere. ;) Any new interpreter in the future plus existing ones would benefit if we said that the C versions were just accelerators instead of the sole implementation.
You’d still need to port every function to Python
Why? My comments about pypy were a footnote to the main point: that functional language people don't hesitate to "build in" any number of functions easily implemented in terms of other ones. This started already with LISP, which very quickly, e.g., added (CADR x) for (CAR (CDR x)), (CADDR x) for (CAR (CDR (CDR x))) and so on - then went on to also add additional spellings (FIRST, SECOND, NTH, etc). The point in that context is to have _common_ spelling and endcase behavior for things - no matter how simple - that are reinvented every day otherwise.
I've been learning Clojure and getting reminded of this again where the uniformity of being able to use these common functions across sequences is where the real power lies. From there you end up with abstractions that everyone can build upon and only care about duck typing against something that's an iterable.
(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).
I'm not at all suggesting to rewrite itertools. I am suggesting that, for most of itertools's natural audience most of the time, an implementation in Python _only_ is "good enough", and that it would best if we recognized that for _new_ itertools functions.
+1, but I wrote https://www.python.org/dev/peps/pep-0399/ so this shouldn't shock anyone. :) -Brett
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.
Different itch. I'm a "practicality beats purity" guy ;-) _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/KBKUC2... Code of Conduct: http://python.org/psf/codeofconduct/