Support for annotations (PEP 484 type hints)

[carljm]

Hi Hynek!

I'd like the generated __init__ signature to include type annotations in Python 3.

Somebody mentioned this in passing over in #63, but after reading through that ticket and glancing at the PR, I'm still not sure how that feature would let me actually get type annotations into the generated __init__ signature. It seems like this requires dedicated support in attrs, probably as a separate kwarg to attr.ib.

Any thoughts?

[hynek]

My thoughts are that that makes sense to have and shouldn’t be too hard to achieve.

The question is how to integrate it. We could pull the type information from the instance_of validator or bite the bullet and introduce a full-fledged on type field that would also help with the deserialization efforts.

[carljm]

I'll have to think a bit about those options. It seems really strange for attr.ib "core" to pull info like that out of a special validator (it's like adding some kind of implicit side-channel to the validator API that only this one special validator gets to use). Also, PEP 484 type hints aren't necessarily expressed the same as runtime types (e.g. for optional types). On the other hand, it's obviously closely related, and would be ugly to have to specify both, especially when they are the same.

The other problem with this whole idea is that PEP 484 hints are mostly for static analysis, and having annotations in import-time generated code isn't going to help those analyzers at all :-) So even with support in attrs to make these annotations available at runtime, making use of them with a type analyzer would require something else (an extension to the static analyzer to understand attr.ib? A generator for type stub files for attr classes?)

[Tinche]

Another thought to consider. In 3.6, this will be possible IIUC:

@attr.s
class A:
    a: int = attr.ib()

I think it would be a great waste not to expose this type information somehow. Probably make attr.Attribute have a type property? In that case we might want to allow versions earlier than 3.6 to set this property somehow too, maybe via an attr.ib() argument.

In any case, once we have this info, it's not hard to add the annotations to the generated init if we want.

[kmike]

Before Python 3.6 annotating attributes was also possible; it is in PEP 484:

@attr.s
class A:
    a = attr.ib(default=None)  # type: int

PyCharm seems to understand such annotations; A().a inferred type is int in PyCharm (likely it just thinks this is a regular class attribute).

But none of PyCharm or mypy understand __init__ method or other generated methods, they both think that __init__ is just __init__(self) and complain when attr.s objects are created with constructor arguments, e.g. A(a=2) is an error in both, which is a bit annoying if a project uses both mypy and attrs.

See also: python/mypy#1310.

[Tinche]

Actually in PyCharm __init__ isn't an error since https://youtrack.jetbrains.com/issue/PY-19130. It won't help you with static analysis either though, just ignore it.

[kmike]

@Tinche yeah, you're right! It shows __init__(self) on inspection, but doesn't complain for unknown arguments.

[wsanchez]

I believe this is the mypy version of this ticket: python/mypy#2088

[hynek]

Closing in favor of #214