In Python, following comment
#--utf8--
indicated the encoding of a source file. In most cases, this won't induce ambiguity, though it's potentially dangerous.
#--utf8--
indicated the encoding of a source file. In most cases, this won't induce ambiguity, though it's potentially dangerous.
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 :)
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.
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 :)
my @blarg = map { foo($_) } grep { $_ > 2 } @y;
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.