On Mon, Apr 20, 2015 at 11:30 AM, Harry Percival <hj...@cantab.net> wrote:
> My first reaction to type hints was "yuck", and I'm sure I'm not the only
> one to think that. viz (from some pycon slides):
>
> def zipmap(f: Callable[[int, int], int], xx: List[int],
> yy: List[int]) -> List[Tuple[int, int, int]]:
My opinion of type hints is: they are great inline, when they are
simple. Cases like (I know its not a real-world case, but there are
plenty of similarly simple functions):
def add(a: int, b: int) -> int:
are fine. When you get more complicated examples, especially when they
involve complex types (list, tuple, callable, etc). In such cases, it
may make sense to predefine a type (I believe the typehints PEP
supports some form of typedef - I think just a simple assignment) and
use that instead of the full type name. This will generally make the
function definition MUCH easier to read.
> That sounds like the best of both worlds to me.
> - .py files stay beautiful, concise, and easy to read.
> - beginners don't have to worry about wading through type definitions when
> they find themselves browsing someone else's source
> - type information is available to the linters and static file checkers, so
> we get all the benefits.
>
> Sounds great right? Everybody will be happy! So let's nail it down! If I
> was in charge, here's what I'd do:
>
> * standardise the syntax for type hints in 3.5, as per PEP484
> * but: recommend the use of stub files as the preferred place to store hints
> * and: deprecate function annotations in the core language
> * remove them from the core language altogether in 3.6
The main drawback of using a stub file is that it is much more likely
to end up out-of-date, and thus useless at best, than if the types are
defined inline. The same issue applies to various alternative
proposals such as having the typehints in decorators, but to a lesser
degree. The same issue also applies to general comments as well.
I would say there are a few major reasons to use stub files:
1) You cannot put the annotations in the source, probably either
because the module is a C library, or you must support versions which
do not support annotations.
2) You must use annotations for other purposes.
3) The annotations are particularly complicated, and you cannot
provide nice names for the various types (likely, because the types
are just very difficult to name, such as in the zipmap example, though
that one might be easier in a more specific context).
Outside of those specific reasons, I would vastly prefer any
annotations to be included in the source, where they are much more
likely to be updated, rather than in a separate file, where they will
likely be forgotten.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
