Then don't do it. Un-nest them always. Simples.
> I get access to reduce[1] which is substantially more powerful than map and filter
Reduce is orthogonal to map/filter.
> Yes, I know that python has map, filter, and reduce. But they're all gimped
No they're not: map [x*2 for x in y], [x*2 for x in y if x > 3] (Syntax not tested, am a bit rusty so may be wrong). Okay, you're not providing a function as a parameter but most of the time with map and filter, that parameter is a constant function not a variable so I still hold this is true. Reduce would be nice as a comprehension, if that's possible.
> by the way python implements lambdas. Which is sort of necessary due to meaningful whitespace
I don't believe whitespace is the problem here. They could fix that pretty easily. I'm really unhappy with python's expression-only lambdas, they do suck.
Sure, that's an option. It's also an option to only write for loops.
I'd prefer to do neither of those. And I get my way in languages that have ergonomic support for map, reduce, and filter.
> Reduce is orthogonal to map/filter.
Reduce is a superset of map/filter.
> No they're not: map [x2 for x in y], [x2 for x in y if x > 3]
I meant the actual map, filter, and reduce functions that are part of python, not list comprehensions that are, admittedly, a fusion of map and filter.
I gave you a solution that solves readability and costs you nothing in performance, and you reject it without saying why. *shrug*
> Reduce is a superset of map/filter
Edit: you're saying that reduce can be abused into a map and a filter. Yes, okay I take your point.
[deleted]
> I meant the actual map, filter, and reduce functions that are part of python
I think you meant "not part of python", I guess I'd agree on that, but then again it's irrelevant. I don't care what mechanism you use to iterate over a list and apply a function to every item, whether it be a comprehension or a map function. The end result is the same, and I'd argue that comprehensions are, or can be, a little cleaner syntactically.
I meant part of python.
https://docs.python.org/3/library/functions.html#map
https://docs.python.org/3/library/functions.html#filter
https://docs.python.org/3/library/functools.html (sadly, I can't link to reduce here)
In addition you previously complain that python doesn't have what you want "I get access to reduce... [in Ruby]" then prove that it does have it, so I don't see what you're saying.
> Clojure is all of the built in functional bits.
Are you saying map, filter, reduce are implemented in the core language and not an add-on library?
I guess, it's true that reduce is part of an included library. But map and filter are "built-in functions". I guess you could make a distinction between those and the language proper, but that's splitting some pretty fine hairs.
> In addition you previously complain that python doesn't have what you want "I get access to reduce... [in Ruby]" then prove that it does have it, so I don't see what you're saying.
Here's what I said:
"Yes, I know that python has map, filter, and reduce. But they're all gimped by the way python implements lambdas."
> Are you saying map, filter, reduce are implemented in the core language and not an add-on library?
If you look at the clojure cheetsheet[1], you can see all of the built-ins (most are functions, some are macros) that Clojure supports (as well as some included libraries).
map, filter, and reduce at all built ins. I strongly doubt that they're supported at the syntax level, but that's kind of lisp's shtick - even stuff like "+" is a built in function, and not "part of the language".
---
My experience is that this is not the case.
Sure, list comprehensions are nice for simple things. But once they start getting complicated - for example double iteration - they start to look fugly. This is a big reason why I strongly prefer ruby over python - I get access to reduce[1] which is substantially more powerful than map and filter. And the syntax for complex expressions stays easy to understand.
I get that that may not be a path that you want to travel, but for me one of the best parts of Clojure is all of the built in functional bits.
> 2. REPL-driven development! Python also has a REPL. True, it isn't the best REPL imaginable, but as far as I can tell it has feature parity with Clojure's! Both are missing the ability to fix errors live in a breakout REPL like you would find in a true LISP REPL.
If you like using the REPL and haven't tried it, ptpython is amazing. A huge upgrade over the default REPL.
> 3. Macros! Code is data! You can easily create your own DSL! OK, maybe. But actually, in Clojure I've gathered the impression that macros are looked down upon, a feature of last resort, unlike in other LISPs. I also can't recall ever using Python and wishing I could replace its syntax with a DSL, since it is already so expressive and flexible. But admittedly that might be a limitation with my own imagination and experience.
Another way to look at macros is that they make it possible to integrate the meta-programming environment - stuff like swagger API generators - into your coding environment.
---
1. Yes, I know that python has map, filter, and reduce. But they're all gimped by the way python implements lambdas. Which is sort of necessary due to meaningful whitespace. And I could just write regular functions instead, but it's not very ergonomic at that point. And it's also un-pythonic.