Python: Even a Feature That You Do Not Use Can Bite You

This is a weird article to me. There seems to be an implicit condemnation of Python for this new feature resulting in non-error, unexpected behavior under certain typoes, despite the fact that that is true for literally any typo that results in valid code in any language (such as, e.g., = instead of ==). I don't understand how it would be possible to add a new syntactic option without being "bit".

Regarding type hints' ability to be arbitrary code, I suspect this is to allow you to use nested type hints from the `typing` library, like `Tuple[int, int]`, as well as more complex or user-defined types. Plus it just gives more flexibility in general.

I'd be interested to hear the author's suggestions on alternative syntax or ways to catch when the programmer intended something other than a type hint, or even arguments that type hints are extraneous and should not have been added - personally, I've found them quite useful recently, in combination with pylint.

In any language that undergoes syntactic extension, there is new syntax that is a syntax error in an old version of the language. Erroneous programs written for the old version which land on that previously bad syntax will undergo a change in behavior.

This is true even in languages that don't undergo syntactic extension. If you call a nonexistent function today, your program bombs. Tomorrow, that function could be added, so now something unexpected happens, perhaps.

Lisps are susceptible. Today (foo bar) is diagnosed; tomorrow it's new syntax (not simply a new function), because foo exists as a macro operator.

However, functions and macros, being named, can be namespaced to curtail such issues. Random, ad hoc read syntax extensions, not so much.

One approach is that files, or sections of files, can support annotations which indicate what version of the syntax is required.

Under GCC, if you want only C89, so that any syntactic extensions from later dialects are invalid syntax, you use '-ansi' on the command line to select that dialect. For oinstance, support for // comments disappears, and so x //blah/ y is x / y, rather than x followed by a comment-to-end-of-line.

Languages can help manage change, though, providing features such that programmers working against older dialects of the language, who make mistakes, get diagnostics according to the old version, rather than accidentally stepping on new syntax.

This isn't a good article to post. It's just one person complaining about a change he didn't know about.

It's really just a syntax change. I probably wouldn't have chosen that particular syntax using colons, or I would have forced another keyword like "set" in front of it, but it is what it is. He created a bug and he likely won't do it again, so problem solved.

I'm not sure how feasible throwing an error is - Type hints in Python can be arbitrary classes or instances thereof, in order to type hint for stuff like nested data structures (`Dict[str: int]`). You could disallow instances of specific built-in classes, but that seems... clunky, especially as some can be used in valid code (strings are used as forward references).