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/[email protected]/thread/QQUS35S4IOV3CR2G3MZNT3RZ2F6TBE4G/
.)
📌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.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/E7HDYWYEAI27OZGY7SGM5GNDS7DM5MRX/
Code of Conduct: http://python.org/psf/codeofconduct/
