spam = None
bacon = 42
def monty(a:spam, b:bacon) -> "different":
pass
Annotations provide a loosely organized way to introduce type checking to your inputs and outputs. They serve as built-in documentation and IDE hinting mechanism, but also provide the ability break early when the function's I/O contract is broken. IMO they are awesome and quite Pythonic.
The fact that the colon and right arrow in a Python annotation are, for the interpreter, a no-op, is insanely confusing to a newbie or just a generalist. It is compounded by how it would have made much more sense to reserve keywords in their places, so instead of
def foo( a : "fruit", b : Color) -> Pineapple:
you could have used reserved names:
def foo( a expects "fruit", b expects Color) returns Pineapple:
Which is a lot more readable in the way Python is meant to be. Good Python code reads more like prose than software, and the former prevents that from happening at all.
Is anybody interested in working on a PEP about this?
Are you on the ML already?
Now it's becoming more like C++, where each hotshot developer want to add his language extension to do some obscure thing nobody really uses except from them and their friends. It will be the demise of Python.
What about this instead: make it faster.
http://www.python.org/dev/peps/pep-3107/#use-cases
>> Despite yet more discussion, it was decided not to standardize a mechanism for annotation interoperability. Standardizing interoperability conventions at this point would be premature. We would rather let these conventions develop organically, based on real-world usage and necessity, than try to force all users into some contrived scheme.