On 12/21/2014 08:05 PM, Guido van Rossum wrote:
On Sun, Dec 21, 2014 at 3:47 PM, Nick Coghlan
mailto:ncoghlan@gmail.com> wrote: On 22 December 2014 at 06:32, Andrew Svetlov
mailto:andrew.svetlov@gmail.com> 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).
What I ended up doing for my scription program was to move the annotations outside the def, and store them in a different attribute, applied with a decorator: @Command( file=('source file', ), dir=('target directory', ), options=('extra options', MULTI, ), ) def copy(file, dir, options): pass copy.__scription__ --> {'file':..., 'dir':..., 'options':...} -- ~Ethan~