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