Stefan Pochmann writes:
> Stephen J. Turnbull wrote:
> > In fact you also created a whole new subordinate data flow that
> > doesn't exist in the original (the [x+1]). I bet that a complex
> > comprehension in your style will need to create a singleton iterable
> > per source element for every mapping except the first.
>
> I don't think so. Sounds like you missed that `for x in [x + 1]` is
> now treated as `x = x + 1` not only by humans but also by Python,
OK, I missed that change.
> That's *more* efficient than your separate iterators having to
> interact, not less.
And more efficient than the separate iterators that would be created
by method chaining in Chris's implementation AIUI. Whose side are you
on here? ;-)
Jokes aside, my opinion matters almost not at all, but I think a lot
of the core devs and in particular the SC will want to see multiple
examples of existing production code that uses alternative idioms such
as comprehensions, generators, and mapping functions that would be
improved by the proposed change.
I doubt you'll find many in the stdlib because Guido and most other
core devs have never been fans of map and filter (even though
eventually those functions moved from functools to builtins). Then,
unless you can present implementations of .map and .filter that
transform
iter(iterable).map(f).filter(g)
to (x for x in iterable for x in [f(x)] if g(x)) as optimized by
Python 3.9+, you'll have to deal with the argument that even though
"readability counts", the better performance of some of the other
idioms reduces the applicability of the method-chaining idiom quite a
lot in production code.
Steve
_______________________________________________
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/YCKVWIJGP3WLYF52VXSASZLEZ46UWFRD/
Code of Conduct: http://python.org/psf/codeofconduct/
