Hacker News new | past | comments | ask | show | jobs | submit login

Anything remotely interesting like that is dumped in itertools.

Python's creator, Guido van Rossum, doesn't like functional/functional-ish programming a lot. That's well-known.

Guido: "I value readability and usefulness for real code. There are some places where map() and filter() make sense, and for other places Python has list comprehensions. I ended up hating reduce() because it was almost exclusively used (a) to implement sum(), or (b) to write unreadable code. So we added built-in sum() at the same time we demoted reduce() from a built-in to something in functools (which is a dumping ground for stuff I don't really care about :-)."




> "I value readability and usefulness for real code"

Amen.

There are plenty of languages where your code ends up looking like an entry in an obfuscation competition without even trying. If you're using Python, and working for me, I expect the code to be readable by anyone.

And, no, I don't give a toss whether the code is three times the length it might have been if it was dangerously, and expensively, obscure.


Quite often, chains of map/filter/reduce/whatever are more readable because you can see the flow of data, like you were looking at a factory production line. List comprehensions and traditional prefix functions (e.g. map(iterable, function)) completely break the visual chain that makes basic functional code so readable.

Like, which of these make more sense?

strList.filter(isNumeric).map(parseInt).filter(x => x != 0)

[ x for x in [ parseInt(s) for s in strList if isNumeric(s) ] if x != 0]

filter(map(filter(strList, isNumeric), parseInt), lambda x: x != 0)

And it's not like Python doesn't have the language features to implement the first pattern. Map,reduce,filter,etc. could simply be added to the iterable base class and be automatically usable for all lists, generators and more.


> Map,reduce,filter,etc. could simply be added to the iterable base class

Surprisingly, Python doesn't have an iterable base class! `list.__bases__` is just `object`.


I believe list comprehensions would be much more readable if they were written the other way round:

    [for x in [for s in strList: if isNumeric(s): parseInt(s)]: if x != 0: x]
Nesting them is still ugly, but can often be avoided using an assignment expression:

    [for s in strList: if isNumeric(s): if (x := parseInt(s)) != 0: x]


if you come from a imperative background and everyone is used to working in imperative languages... I guess thats anyone.

Someone coming from, say ruby, or javascript would find list comprehension jarring. You can't compose them and you basically have to rewrite them when its time to extend them.

readable by anyone is pretty subjective.


Yes, lots of them are available. But I also would like to be able to call .sum() on my iterable at the end of a chain, instead of having to mentally unwrap sum(map(filter(filter(map(...))))


I bet a Clojure-style ‘threading’ arrow function can be easily done in Python.

  arrow(my_list [map args] [filter args] [filter args] [map args] [sum])
For cases when function argument positions differ, you'll need some special var in your module to signal where to inject the list.

  arrow(my_list [map map_func arrow.list_here])
Won't be surprised if something like this already exists, but I can't think of keywords to search for that aren't too generic.


> But I also would like to be able to call .sum() on my iterable at the end of a chain

Yeah, one thing I like about Ruby over Python is the fluent code th former allows of that style.

People talk about Guido not liking functional style, but that explains comprehensions over map/filter, but not function-sum() over method .sum().


But you only ever need to unwrap one sum(). And with sequence comprehensions, what you get instead is sum(... for ... if ... for ... if ...) - I don't think that's improved by rewriting it as (...).sum().


There's a not unreasonable position implicit in Python's way that the "most significant" operation should be most visible.

The problem with filter chaining is the final assignment and the actual value are separated by the rest of the chain.

i.e. x = strList.filter(parseInt).sum() doesn't tell me what type x is till I read the whole line.

Whereas:

x = sum( parseInt(v) for v in strList ) tells me as quickly as possible that I'm dealing with a single value output that will be a sum.


I strongly dislike python, I often wonder if it would have been as popular if Guido didn't work at Google early on.


Guido joined Google in 2005, and it was already plenty popular by then.


FWIW Python was fourteen years old when GVR joined the Borg. That doesn't address how popular it was but I think it's reasonable to say it was well established.


Why do you strongly dislike Python? Language design, standard library, community, leadership?


Mostly language design.

Guido van Rossum doesn't appreciate FP and he really genuinely doesn't understand it. That's not to say he's dumb or not a nice guy or anything. It's just not his area. And this is reflected in the language.

His attitude of you have to be "really smart" to understand FP is a mistake.

https://developers.slashdot.org/story/13/08/25/2115204/inter...

https://blog.finxter.com/about-guidos-fate-of-reduce-in-pyth...


Also definitely learn about using sum on non-numbers, and the key argument to min and max. They can be incredibly handy, but I hardly see them used. Have a contrived example:

    >>> max(['aaa', 'bb', 'c'], key=lambda item: len(item))
    'aaa'




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: