Hi, I'd like to revive this thread after what seemed like a decade and see where this might take us 😃 I like this idea that the OP suggested but I'd like to extend this to all iterator objects (range_iterators, list_iterators etc.). 📌Idea Iterables to expose the .__iter__() method in iterable as .iter(). Iterators to implement 'transformational' functions like map, filter, flat_map, 'reductional' functions like reduce, sum, join, and 'evaluate' functions like to_list and to_set. ( [1,2,3].iter() .map(lambda x: x+1) .filter(lambda x: x % 2 == 0) .to_list() ) 📌Why? 1. It is readable in a manner that is procedural and dataflow centric. At one glance, it is easy to reason about how our data gets transformed - we start with the subject, our data, then we perform a sequence of transformations. The previous way of doing this: list( filter( lambda x: x%2==0, map( lambda x: x+1, iter([1,2,3])))) incurs a lot of cognitive overload. We could separate them into different lines: it = iter([1,2,3]) it = map(lambda x: x+1, it) it = filter(lambda x: x%2==0, it) list(it) but I would argue that there is a lot of repetition. 2. There are existing communities which deal with frameworks that focus on data transformations. This includes PySpark and pandas. 3. It is conventional - many modern languages like Rust, Scala, JavaScript and Kotlin have a similar API like this. 4. The existing map, filter APIs are not so commonly used (this is the impression I have). Apparently list comprehension appears more pythonic on StackOverflow posts. This extended iterator API could possibly 'revive' the use of lazy evaluation. 5. This API is 'flat', rather than the 'nested' map, reduce and filter. (I guess we can argue that "Flat is better than nested"?) 📌Why not? 1. Method chaining is uncommon and not really well-liked. I have this impression a lot among the community. Could somebody please explain why? 2. A lot of 'lambda' keywords. Agreed. (However, this would tie in well with the alternate lambda syntax proposal https://mail.python.org/archives/list/python-ideas@python.org/thread/QQUS35S... .) 📌On list comprehension vs. method chaining I don't think the aim of this API should be to replace list comprehension and the like. Rather it offers programmers an alternative pattern to transform and reason about their data.