Other uses of annotations

[mvitousek]

Currently the proposal suggests a dictionary-based syntax for allowing the arbitrary annotations currently used in Python 3 to coexist with type annotations (https://github.com/ambv/typehinting/blob/master/pep-NNNN.txt#L194):

def notify_by_email(employees: {'type': List[Employee], 'min_size': 1, 'max_size': 100}): ...

This meshes well with existing usage if the existing non-type annotation is already a dictionary, but if it's some other kind of value it forces additional refactoring. Maybe instead, typing could provide a TaggedType or similar class, which cleanly separates type information from other information that the programmer wants in their annotations:

def notify_by_email(employees: TaggedType(List[Employee], {'min_size': 1, 'max_size': 100}): ...
or
def notify_by_email(employees: TaggedType(List[Employee], 'list of employees to be notified')): ...

The first argument is always a type, and the second argument is any arbitrary value.

This would also free up dictionaries for possibly representing structural types/protocols (see #11).

[gvanrossum]

This is one of my least favorite parts of the draft. I haven't had time to
come up with something better, but the dictionary notation is too verbose
to my taste. I'm not sure that your TaggedType proposal is any less verbose
though.

On Thu, Nov 6, 2014 at 4:45 PM, Michael Vitousek notifications@github.com
wrote:

Currently the proposal suggests a dictionary-based syntax for allowing the
arbitrary annotations currently used in Python 3 to coexist with type
annotations (
https://github.com/ambv/typehinting/blob/master/pep-NNNN.txt#L194):

def notify_by_email(employees: {'type': List[Employee], 'min_size': 1, 'max_size': 100}): ...

This meshes well with existing usage if the existing non-type annotation
is already a dictionary, but if it's some other kind of value it forces
additional refactoring. Maybe instead, typing could provide a TaggedType
or similar class, which cleanly separates type information from other
information that the programmer wants in their annotations:

def notify_by_email(employees: TaggedType(List[Employee], {'min_size': 1, 'max_size': 100}): ...
or
def notify_by_email(employees: TaggedType(List[Employee], 'list of employees to be notified')): ...

The first argument is always a type, and the second argument is any
arbitrary value.

This would also free up dictionaries for possibly representing structural
types/protocols (see #11 #11).

—
Reply to this email directly or view it on GitHub
#26.

--Guido van Rossum (python.org/~guido)

[JukkaL]

I don't like this much. I think having function or file level granularity would probably be sufficient. Perhaps use a function decorator for escaping out of type annotations (somebody suggested this already). Here is the first thing than came to mind:

from typing import ignore_annotation as mydecorator

@mydecorator
def f(x: ('my', 'own', 'annotation')) -> 'not a type':
    ...

If we have a fallback approach for annotating Python 2 code in a way that makes the types available for introspection, we could use this to have multiple annotations. For example (similar to the proposal by Andrey Vlasovskikh -- https://github.com/JukkaL/typing/issues/12):

from typing import annotations, ignore_annotation

@annotations(x=int, returns=str)
@ignore_annotation
def f(x: 'my annotation') -> 'totally non-standard':
    print(x + 'x')   # type error

This is still not great, IMHO, but I think that it's less bad than the alternatives that have been proposed.

[ambv]

The decorator idea to turn off the checker is a good one.

[gvanrossum]

Let's do a decorator in typing.py to silence the static checker. It should
work for classes and functions/methods.

Let's not do a decorator to add annotations (I think the use cases would be
too uncommon).

Proposal for the name: @no_type_check or @skip_type_check.

On Wed, Jan 7, 2015 at 12:11 AM, Łukasz Langa notifications@github.com
wrote:

The decorator idea to turn off the checker is a good one.

—
Reply to this email directly or view it on GitHub
#26 (comment).

--Guido van Rossum (python.org/~guido)

[ambv]

@gvanrossum, agreed with just adding the silencing decorator.

Bike shedding for a second, you decide. Skip underscores maybe?

1. @classmethod, @staticmethod, @contextmanager, lots of single word ones like @asyncio.coroutine.
2. Counter examples: @lru_cache, @total_ordering, etc.

[gvanrossum]

Let's do @no_type_checks. (Or, more verbose, @typing.no_type_checks.)

We may still have a comment too (I'm undecided on that, but comments are not ruled out).

[ambv]

Fixed in e2e6fc4 (comment named as "type: ignore" for now).

[JukkaL]

Added mypy issue: python/mypy#557

[gvanrossum]

Update: it should be @no_type_check and @no_type_check_decorator as was chosen for the PEP and in some other discussion (can't find the issue right now).