On Mon, Dec 9, 2019 at 10:03 AM Tim Peters <tim.pet...@gmail.com> wrote:
> [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. > 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-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/ >
_______________________________________________ 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/QKJHS33JFRWYCJYZSUAQM766P7W7RYEL/ Code of Conduct: http://python.org/psf/codeofconduct/
