Forward references

[Tinche]

Hello, there's some food for thought. Imagine a class referencing itself.

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

This is the proper way of doing this as per mypy. In the case of attrs though:

>>> attr.fields(A).a
Attribute(name='a', default=NOTHING, validator=None, repr=True, cmp=True, hash=None, init=True, convert=None, metadata=mappingproxy({}), type='A')

The string just gets copied into the type attribute. A.__annotations__ has the same problem. Ideally the type would be the actual class object. Mypy deals with this by having more than one pass when parsing.

The first question to answer if whether we should deal with this here, in attrs, or let code making use of the type attribute deal with it. Maybe instead of expecting higher levels to deal with this, Python itself should handle it (although good luck waiting for this :). I think it's worth trying to deal with this problem in attrs, to make it easier for others.

Dealing with just a class referencing itself is very doable. Now imagine circular references.

@attr.s
class A:
    b: 'B' = attr.ib()

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

Not really sure what to do here.

[Tinche]

This issue was initially motivated by https://github.com/Tinche/cattrs/issues/13.

[wsanchez]

GitHub doesn't have enough Emojis for this one.

[vodik]

As I understand it, and especially with PEP 563 in the picture, I'd argue the current behaviour is the most correct one. Especially as performance was one of the motivations for the change:

type hints are executed at module import time, which is not computationally free

typing.get_type_hints() already works as expected on attr classes.

[hynek]

Is this still relevant with from __future__ import annotations @Tinche? My gut feeling is that if we start doing our own thing, it’s gonna fall on our feet.

[Tinche]

Yeah, I haven't really looked into this in depth again yet but I think this is out of scope for attrs now.

[hynek]

FYI we have attr.resolve_types() now.