[Andrew Barnert <abarn...@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. > 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. > (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. > 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-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/KBKUC2O3O6G35Q67JQX62XMRPM6ANDDV/ Code of Conduct: http://python.org/psf/codeofconduct/
