I'm truly baffled by how insane the `map/reduce/filter` iterator API for #Python is. Most languages, even JavaScript, have some sort of "other_list = the_list.map().filter()" API. Except Python (and PHP?).

Now, I can imagine that a language that primarily deals with string manipulation or DOM management or so, to have a crappy API for handling large lists of data. But python's entire success comes from "handleing large lists of data", yet the tools to do so are infuriating.

@berkes I'm fairly certain Python has this, but before i go figure out the exact syntax I want to understand your ask a bit better. Are you saying the functionality doesnt exist at all, or simply that you cant chain them together and they need to be on seperate lines, or something else I'm missing?

@berkes

Python does have the functions though:

filter(other_func, map(the_func, the_list))

That should be roughly the same as what you asked for... Are you just complaining about the syntax, seems functionally pretty interchangable.

@freemo I was referring to that. The insanity being that they are global functions and not something you call on a iterator like every other language has.

@berkes @freemo In Python they are functions, not methods, because they work with any iterable (strings, lists, tuples, bytes, literraly any containers, even the ones you create). It's easier than having to implement a map and a reduce function on every container.

But in Python we don't even use map and filter, comprehensions are (very often) more readable:

>>> sum(map(abs, filter(lambda x: x > 10, the_iterable)))

vs

>>> sum(abs(x) for x in the_iterable if x > 10)

@mdk

To be fair IMO all collections should have a common parent class, this would have all the common stuff like map, filter, getting the iterator, etc. I do agree with berkes that doing it as a method would look nicer and feel nicer.

That said, I cant think of any situation where it makes any sort of functional difference.

@berkes

@freemo @mdk it hardly makes theoretical difference.

But the ergonomics and the communication are very different.

Ergonomics: Many other methods in python act 'on the thing' (str.capitalize() etc). So it's inconsistent.
Chaining isn't possible: thelist.map().filter().sort().reduce() vs reduce(sort(filter(map(thelist))). Gets worse with multiline lambdas.

Comms: custom classes can have iterator methods implemented (ie a custom .sort()) But they cannot introduce global methods.

@berkes

All but the last point are valid but purely aesthetic.

The last poi t about overriding is valid, though i doubt there is much need to override, there may be some edge cases.

Lets face it this is python, they gave up on aesthetics a long time ago.

@mdk

@freemo @mdk You make it sound as if ergonomics aren't important.

@berkes

aesthetics != ergonomics.

The use of the global function has exactly the same number of key presses to represent it. It may look ugly, but beyond that there is no down side. Ergonomics implies it makes the problem physically straining, it does not.

Ugly vs pretty isnt really important, not in a utilitarian sense. For me I weigh aesthetics higher than most and it will effect my desire (or rather lack thereof) to use python. But I recognize that is really just a silly quirk of mine and not a functional black mark against the language.

@mdk

@freemo @mdk You have a completely different (wrong?) definition of ergonomics in software. Aesthetics is *part of* ergonomics.

As is a **readable and expressive syntax, an effective standard library**, good tooling, and so on.

having to read backwards from deeply nested function calls is neither of these. And, indeed, it also looks ugly, but that's the least of the concerns.

@berkes

> You have a completely different (wrong?) definition of ergonomics in software. Aesthetics is *part of* ergonomics.

No it isnt. How pretty something looks, when it has no effect on usability itself, does **not** fall under ergonomics. Ergonomics is defined as the following:

"Ergonomics is a body of knowledge about human abilities, human limitations and other human characteristics that are relevant to design. Ergonomic design is the application of this body of knowledge to the design of tools, machines, systems, tasks, jobs and environments for safe, comfortable and effective human use"

Therefore things like "this can be done in less lines of code" would be ergonomics, but "this looks pretty but has no other advantages" is not. Ergonomics is always about usability, not how pretty something is.

> As is a **readable and expressive syntax, an effective standard library**, good tooling, and so on.

If that described what we are talking about then yes, I'd agree it is an ergonomics issue. However the two syntaxes have absolutely no different in their readability or expressiveness. Which is why I say this has nothing to do with ergonomics. If one syntax actually was easier to read or write then I might agree, but as pointed out both are equal and even have the smae number of key presses. Actually if you want to get technical the python version needs one less key pres (the dot) and thus would be the more ergonomic of the two.

> having to read backwards from deeply nested function calls is neither of these. And, indeed, it also looks ugly, but that's the least of the concerns.

You dont have to "read backwards", you are reading forwards with that syntax. It is only "backwards" if you consider your preferred syntax as forward, which is arbitrary.

Its like saying "Joe rides the horse" is a bad sentence because its backwards and "The horse is ridden by joe" is the correct one because its forwards. When in reality they are just reverse order of eachother and neither is the privileged "forward" version.

@mdk