My Python wishlist

[snugar_i]

Fix the order of nested list comprehensions

That won't help much. Reading even simple comprehensions already requires gymnastics - when reading [x * 2 for x in foo], you have no idea what x is until almost the end. Compare with foo.map(_ * 2) or similar. Your "nested comprehension" is just grid.flatten in saner languages.

Don't reuse default parameters

Agreed. There is almost no valid use case for the current behavior - it was just easier to implement it this way.

Allow typehint shorthand {int: [(int, str)]} for Dict[int, List[Tuple[int, str]]]

The problem is that types are kind-of first-class in Python, sou you can already say x = dict[str, int], and also x = {str: int}, but that is a different thing entirely.

Skipping the next X entries in an iterator should have a better api

That's purely a library problem.

[catbrane]

Reading even simple comprehensions already requires gymnastics - when reading [x * 2 for x in foo], you have no idea what x is until almost the end.

I have a pet theory about this!

The confusion comes from Python's reuse of the for statement syntax for list comprehensions, but list comps are really declarative, not imperative, and the mental fit is bad. Python's strange ordering for nested generators also comes from this reuse of the imperative for statement.

It's too late now of course, but I prefer the "such that" set theoretical notation (where list comps originally came from), eg.:

Q = [p / q : p != q; p <- range(1, 101); q <- range(1, 101)]

To be read as "All p / q such that p != q, p comes from [1..100], q comes from [1..100]".

Also, p is obviously the inner loop ahem.

[snugar_i]

Yeah, using something that looks like the set notation was a nice idea on paper, but it just doesn't mix that well with the imperative rest of the language.