Other uses of annotations about typing HOT 9 CLOSED

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 [email protected]
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)

from typing.

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.

from typing.

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

from typing.

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 [email protected]
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)

from typing.

@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.

from typing.

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).

from typing.

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

from typing.

Added mypy issue: python/mypy#557

from typing.

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).

from typing.