Typechecking attrs-generated classes

[lvh]

attrs removes object boilerplate:

>>> import attr
>>> @attr.s
... class C(object):
...     x = attr.ib(default=42)

This has many advantages, like eq/hash behavior working, reprs working, easy to add runtime validators, &c. However, it's not obvious to me how I can typecheck creating instances of this, because there's no __init__. (I'm using Python 2.7, so comment syntax, if it matters :))

[gvanrossum]

Hi Laurens, this looks like something that should be doable with the (as yet hypothetical) plugin architecture: #1240

[wsanchez]

A bit more detail, as the problem here isn't just that you can't validate attrs class initializer usage using mypy (and, in fact, you can validate types at runtime using attrs), but also that mypy is emitting false positives, which makes mypy harder to use if you use attrs.

Here's a script thing.py:

from pathlib import Path

from attr import attrib, attrs
from attr.validators import instance_of


@attrs()
class ThingWithPath(object):
    _path = attrib(validator=instance_of(Path))

    def exists(self):
        return self._path.exists()


thing1 = ThingWithPath(Path("."))
print("thing1 exists:", thing1.exists())

thing2 = ThingWithPath(path=Path("."))
print("thing2 exists:", thing2.exists())

Which runs thusly (note the runtime type validation, if that's a thing you like):

wsanchez$ python thing.py
thing1 exists: True
thing2 exists: True
Traceback (most recent call last):
  File "thing.py", line 21, in <module>
    thing3 = ThingWithPath(".")
  File "<attrs generated init 72ca13b0f10a00b12fb26accfd84d196fc2af0c6>", line 5, in __init__
  File "/Users/wsanchez/Dropbox/Developer/PIE/wsanchez/ConfigService/.tox/py35-coverage/lib/python3.5/site-packages/attr/validators.py", line 24, in __call__
    attr, self.type, value,
TypeError: ("'_path' must be <class 'pathlib.Path'> (got '.' that is a <class 'str'>).", Attribute(name='_path', default=NOTHING, validator=<instance_of validator for type <class 'pathlib.Path'>>, repr=True, cmp=True, hash=True, init=True, convert=None, metadata=mappingproxy({})), <class 'pathlib.Path'>, '.')

Running mypy on this script emits:

thing.py:15: error: Too many arguments for "ThingWithPath"
thing.py:18: error: Unexpected keyword argument "path" for "ThingWithPath"
thing.py:21: error: Too many arguments for "ThingWithPath"

And mypy of course exists with a non-zero status.

[gvanrossum]

It's unfortunate, but not unique to attrs -- this is a general problem when you have a metaclass or a class decorator that affects the API of a class. I suppose we could teach mypy to special-case attrs, but that just moves the problem to every other library engaging in such tricks.

A more principled approach would be to add some new magic primitive to PEP 484 (and support in mypy of course) that would allow one to write a stub for attrs that explains to mypy what the effect of the class decorator is. This might be easier now than when this issue was created given that we already have some support for metaclasses now (#2475), so some of the necessary scaffolding in mypy already exists.

You could also imagine that mypy could just parse the full source code for the attrs package and understand what it does without needing any help. But I think that's unlikely to be successful, due to the difficulty for mypy to understand the dynamic tricks such an implementation undoubtedly uses. (I haven't looked.)

In general, supporting code that does runtime manipulation of interfaces is not high on the list of things that mypy and PEP 484 are likely to support soon. It's generally a bit antithetic to the idea of static types, after all. :-)

[wsanchez]

Yup, I was just trying to be more specific about the issue here.

I'm not sure I agree that attrs (or at least its functionality) is "antithetic to the idea of static types". I understand why it creates challenges here, but the degree to which it does dynamic things is limited to one time when the class is created, not some random manipulations as the program is running.

That said, I'm fairly new to mypy and the typing system.

I agree that being able to write a stub would be useful absent more robust but considerably harder to implement solutions.

[ryanhiebert]

I'm not sure I agree that attrs (or at least its functionality) is "antithetic to the idea of static types".

I agree with this assessment. attrs itself is not antithetical, though it's current implementation obviously is. It's really about supporting better use of types, by making them simpler to declare and be useful. I'm sure that if there were a way to support type systems at the same time, that would definitely fall in line with the goals of attrs.

Whether the real solution is pluggability for the type system to allow for this kind of compile-time transformations, or whether the only real solution is to have something that fulfills the goals of attrs built into the language, I'm not sure, but they are two approaches that are both trying to encourage the proper use of types. The dynamic implementation is just that, an implementation detail.

[gvanrossum]

Well, mypy doesn't execute the program. It just reads the source code. So in order to validate the ThingWithPath() calls it would have to know the signature of the __init__() method that is added by the @attrs decorator, which in turn depends on going over the class attributes looking for expressions of a whatever type is returned by attrib(). Figuring that out presumably requires understanding the attrs package thoroughly, which is not possible given the state of the art and mypy's limited understanding of source code.

[fxfitz]

If it helps anyone, we solved this problem recently (specifically with attrs) where we define the init ourselves for attrs. Maybe it could help someone else too! Reusing the example from above:

@attrs(init=False)
class ThingWithPath(object):
    _path = attrib(validator=instance_of(Path))

    def __init__(self, _path):
        self._path = _path

    def exists(self):
        return self._path.exists()

[ambv]

There's discussion on an API in attrs (here: python-attrs/attrs#151) that would help bridging this. I'm following along since I like both typing and attrs for removed (and always correct!) boilerplate.

[wsanchez]

@fxfitz: As @ambv notes, the problem there is that your solution removes one of the big benefits of attrs. And presumably that prevents attrs from doing the validation it would have done in the generated __init__, no?

I suppose that if attrs nuked and replaced your __init__, that may work, and then you'd instead write:

@attrs()
class ThingWithPath(object):
    _path = attrib(validator=instance_of(Path))

    def __init__(self, _path: Path):  # Note added type annotation here
        pass  # This implementation isn't used, so pass

    def exists(self):
        return self._path.exists()

It would be confusing for someone who may put code into __init__ not knowing it's ignored… so it's not 100% great, but maybe better.

[fxfitz]

@wsanchez Ah right, I forget that if you init=False you would lose your validation; my bad! We used a similar approach to what I suggested earlier, but our goals were to (1) get mypy working and (2) still use attrs for the working equality/hash checks.

[Tinche]

Hello, I'm one of the attrs maintainers.

I think it's fair to say mypy will have a really hard time ever working out of the box with attrs since we do some really filthy things under the hood.

I also think making attrs work with mypy would be a very worthwhile thing to try to do, since the point of attrs is to make people use structured data more and this is very complimentary to the idea of static typing checks.

I'd be interested in maybe being involved with the effort to develop a plugin API, if that's the direction we're going in, and ultimately developing a plugin for attrs.