Other uses of annotations #26

Activity

1. gvanrossum commented on Nov 7, 2014

   

   gvanrossum

   on Nov 7, 2014

   Member

   More actions

   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)
2. JukkaL commented on Nov 9, 2014

   

   JukkaL

   on Nov 9, 2014

   Contributor

   More actions

   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.
3. ambv commented on Jan 7, 2015

   

   ambv

   on Jan 7, 2015

   Contributor

   More actions

   The decorator idea to turn off the checker is a good one.
4. gvanrossum commented on Jan 7, 2015

   

   gvanrossum

   on Jan 7, 2015

   Member

   More actions

   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)
5. ambv commented on Jan 8, 2015

   

   ambv

   on Jan 8, 2015

   Contributor

   More actions

   @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.
6. gvanrossum commented on Jan 8, 2015

   

   gvanrossum

   on Jan 8, 2015

   Member

   More actions

   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).
7. ambv commented on Jan 14, 2015

   

   ambv

   on Jan 14, 2015

   Contributor

   More actions

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

   closed this as completedon Jan 14, 2015
9. JukkaL commented on Jan 17, 2015

   

   JukkaL

   on Jan 17, 2015

   Contributor

   More actions

   Added mypy issue: python/mypy#557
10. gvanrossum commented on Apr 20, 2015

    

    gvanrossum

    on Apr 20, 2015

    Member

    More actions

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