Bèr Kessels 🐝 🚐 🏄 🌱
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.
🎓 Doc Freemo :jpf: 🇳🇱
@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?
🎓 Doc Freemo :jpf: 🇳🇱
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.
🎓 Doc Freemo :jpf: 🇳🇱
@berkes on an iterator or on an interatable collection?
Regardless functionally how is there any meaningful difference?
Bèr Kessels 🐝 🚐 🏄 🌱
@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.
🎓 Doc Freemo :jpf: 🇳🇱
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.
Julien Palard
@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 method 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)
🎓 Doc Freemo :jpf: 🇳🇱
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.
Bèr Kessels 🐝 🚐 🏄 🌱
@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.
🎓 Doc Freemo :jpf: 🇳🇱
They could have done it sure. I dont think anyone is denying the style you suggest isnt doable.
Bèr Kessels 🐝 🚐 🏄 🌱
@mdk @freemo Python could have the Ruby way where iterators are modules (shared behavior) that's mixed in. Or java, where it's an interface. Or the rust way where .iter() turns anything that wants to, into an actual Iterator.
If the reasons are 'technical limitations' it only strengthens my point that Python is doing a poor job here.
🎓 Doc Freemo :jpf: 🇳🇱
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.
Bèr Kessels 🐝 🚐 🏄 🌱
@freemo @mdk You make it sound as if ergonomics aren't important.
🎓 Doc Freemo :jpf: 🇳🇱
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.
Bèr Kessels 🐝 🚐 🏄 🌱
@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.
🎓 Doc Freemo :jpf: 🇳🇱
No the definition is the same, just more specific in software.
Here is the definition of software ergonomics (soft ergonomics) which is clearly in line with the general definition:
Soft ergonomics is the study of designing virtual interfaces that cater towards the wellness of the human body, its emotional and cognitive abilities.
Soft ergonomics is a subset of ergonomics and human factors engineering, a larger body of the study of human abilities for designing equipment and devices that fit the human body. Soft ergonomics can be thus defined as the ability of any virtual interface(computer application, website, ATM options, parking meter etc.) to make it comfortable for the user to use the interface while working on the user's request.
Bèr Kessels 🐝 🚐 🏄 🌱
@freemo like I said. A very different (wrong?) definition of ergonomics in *programming languages*.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.