[Python-ideas] PEP 484 (Type Hints) -- first draft round

[Cem Karan]

On Jan 16, 2015, at 4:40 PM, Guido van Rossum <guido at python.org> wrote:

> On Fri, Jan 16, 2015 at 12:34 PM, Dennis Brakhane <brakhane at googlemail.com> wrote:
> Am 16.01.2015 um 20:45 schrieb Guido van Rossum:
> > That's discussed in this section:
> > https://www.python.org/dev/peps/pep-0484/#compatibility-with-other-uses-of-function-annotations
> > .
> I still feel that saying "if you use function annotations, that function
> cannot be statically checked" is bad.
> 
> If type hints are successful, many projects will adopt them, especially
> big projects and/or projects in corporations. Probably many will require
> that all code must pass the type checker, and (at least) public
> functions be type annotated.
> 
> Let's suppose that indeed happens. If I now were writing a new open
> source Python library, I would want that my library could be used in big
> projects, and therefore would have an incentive to type annotate my
> library. If I don't, a big project might choose another lib instead that
> does.
> 
> So in that future, a library that wants to be successful basically can't
> use type annotations, even if they would have been an elegant solution
> to a particular problem. That feels somewhat wrong to me.
> 
> A possible work around using skeletons seems ugly, you would have to
> edit two different files and keep them in sync.
> 
> I feel there should be another way to make type annotations and
> "creative" annotations coexist.
> 
> The cleanest way to do this would be to use decorators for the non-type-hint use case.
>  
> 
> 
> > The dict notation (which was proposed in an earlier thread on
> > python-ideas) looks too messy to seriously support.
> How about using a tuple? I'll admit that I've proposed it before, but
> got no reaction.
> 
> If an annotation is a tuple, the type checker would check each element
> for known values, and every other thing that uses __annotations__ could
> do the same. Stefan's example could look something like
> 
>   def func(x: (str, wobble(False), ctype('std::string[utf8]'))) -> (str,
> wobble(True))
> 
> It's still not pretty, but it has the advantage that it is only needed
> for when more than one annotation is used.
> 
> It's very ambiguous though. Especially since plain strings are taken to be type annotations (used for forward references).
>  
> It has the disadvantage of preventing (int,str) being an alias for
> Tuple[int,str].
> 
> But we're not proposing that (overloading native container syntax for types was proposed and rejected early on). 
> 
> Actually, I don't care that much what particular solution is used to
> allow type annotations and non-type annotations to coexist, but I find
> it important that is possible.
> 
> Decorators.

If we're using decorators for the annotations, why not use them for the typing as well?  E.g.,

@typing.type(a, int)
@doc.doc(a, "some doc")
def f(a):
    pass

This would be the equivalent of:

def f(a: {"typing.type": int, "doc.doc": "some doc"}):
    pass

The whole dictionary idea will be hidden, and annotations can be used for other purposes while still supporting typing information.  I'll admit that stacking the decorators means the code could get very deep, but it still feels like the least bad thing to do.

Thanks,
Cem Karan