I was going to say it's the only one Python 2 has, AFAIK. So they've kept it reaosnable there, but then I remembered this:

https://www.python.org/dev/peps/pep-0484/#id24

Which is pretty scary, IMHO.

Python is productive, but I always questioned some of the choices in the language design (broken lambdas, etc -- though the implementation of list comprehensions were great so I just learned to love them) -- but it seems to take some of the same decisions Go is taking in terms of inconsistencies now.

The Go stuff, however, seems much more worse.

The phrase "nothing but Perl can parse Perl" comes to mind :)

The decision to put type annotations for variables in comments was made specifically for backwards compatibility reasons.

Remember that Python has supported function annotations since 3.0 [0]. Python 3.5 will only add the option to type check those same annotations.

Any type annotations that can be checked by Python 3.5 can also be parsed by earlier versions of Python, though without being checked.

The only wart in this master plan is specifically the one where you want to type annotate variables (as opposed to functions). Comments are the only way they could do this in a backwards compatible way.

The Python devs are well aware of the ugliness of this compromise, which is why they end the section you linked to with this:

> If type hinting proves useful in general, a syntax for typing variables may be provided in a future Python version.

I can't comment on Go, but I wouldn't call Python's choice here unreasonable.

[0] https://www.python.org/dev/peps/pep-3107/

Python's list comprehensions always struck me as an odd way to go given Python's tendency to choose clarity and simplicity over complexity and expressiveness. As a Perl user, Python list comprehensions make me go cross-eyed half the time. It's something Perl specifically decided to forego as too complex and prone to causing confusion, which is saying something.

Nesting them I feel is almost always bad

blarg = [ foo(x) for x in y if x > 2]

I think is pretty decent. Helps if they are calling named functions, so it's more self documenting, depending on complexity.

Dict comprehensions can be a little brain-warping too :)

Yeah, the Perl equivalent of that is:

  my @blarg = map { foo($_) } grep { $_ > 2 } @y;

A bit more verbose, but if you know Perl, obvious (and the same building blocks allow for more powerful constructs[1], since they really are functional code blocks).

You can argue the Python version is clearer, but placement of the conditional always throws me off. I like to think of my transforms as a pipeline.

1: http://en.wikipedia.org/wiki/Schwartzian_transform

That may have been a hack based on emacs where you can set various file options with comments like that.