On Sun, Dec 21, 2014 at 3:47 PM, Nick Coghlan
On 22 December 2014 at 06:32, Andrew Svetlov
wrote: Sorry, I want to ask again. The proposal is for static checks only? My expectations for processing annotations in runtime as-is (just a mark without any restrictions) will not changed?
Correct, there are no changes being proposed to the runtime semantics of annotations. The type hinting proposal describes a conventional use for them that will be of benefit to static type checking systems and integrated development environments, but it will be exactly that: a convention, not an enforced behaviour.
Well... The elephant in the room is that *eventually* other uses of annotations *may* be frowned upon, or may need to be marked by some decorator. But I promise that in Python 3.5 your code will not break -- it just might not be very useful to run a static checker like mypy on it. (IIRC mypy used to only typecheck code that imports the typing.py module, but this seems to have changed.) When we discussed this earlier this year, a few other uses of annotations were brought up, and some have proposed that static type annotations would need to be marked by a decorator. There is even a proposed syntax that allows multiple annotations to coexist for the same argument (a dict with fixed keys -- to me it looks pretty ugly though). I would really like to wait and see how this plays out -- the proposal I'm working on is careful not to have any effect at runtime (as long as the typing.py module can be imported and as long as the annotation expressions don't raise exceptions), and use of a static checker is entirely optional and voluntary. Perhaps the PEP should define some way to tell the type checker not to follow certain imports? That would be useful in case you have a program that tries to follow the annotation conventions for static checking but imports some library that uses annotations for a different purpose. You can probably do this already for mypy by writing a stub module. -- --Guido van Rossum (python.org/~guido)