Any plans to support attrs?

[kellerza]

Currently the AttrsInstance protocol matches any attrs object in mypy & pyright. More here: https://www.attrs.org/en/stable/types.html

Today, this raises the following

error: Argument 1 to "do_something" has incompatible type "Data1"; expected "AttrsInstance" [arg-type]

@attrs.define()
class Data1:
   s : str = "s"
   n: int = 1

def do_something(inst: AttrsInstance) -> None:
    pass

inst = Data1()
do_something(inst)

Any plan to support attrs?

[SuperHeroDev505]

Right now this behavior is expected in Pyright.

Mypy has special casing for attrs classes. It understands that a class decorated with @attrs.define() structurally satisfies the AttrsInstance protocol. Pyright does not implement that special handling, so it treats AttrsInstance as a normal protocol. Since Data1 does not explicitly inherit from it and the structural shape does not match what Pyright expects internally, it reports the argument type error.

So the issue is not with your class definition. It is a type checker feature gap.

At the moment, Pyright does not provide full parity with mypy’s attrs plugin behavior. There has been discussion about improving attrs support, but it requires explicit modeling of attrs semantics inside the type checker. Without that, protocols like AttrsInstance will not automatically match.

If you need a working solution today, you have a few options:

You can avoid using AttrsInstance in the signature and instead type against a more general bound such as Protocol or Any.

You can introduce a type variable bound to a base class if you control the hierarchy.

Or you can use mypy for projects that depend heavily on attrs specific typing behavior.

In short, this is not a problem with attrs itself, but a difference in how static analyzers implement support. Pyright would need explicit attrs awareness to behave like mypy here.

[kellerza]

also get it for others in that same class... alway an init=False field

src\ha_addon_sunsynk_multi\a_inverter.py:263: error: Trying to assign name "entity_timeout" that is not in "__slots__" of type "src.ha_addon_sunsynk_multi.a_inverter.AInverter"  [misc]
src\ha_addon_sunsynk_multi\a_inverter.py:273: error: Trying to assign name "entity_cbstats" that is not in "__slots__" of type "src.ha_addon_sunsynk_multi.a_inverter.AInverter"  [misc]

[kellerza]

Are these the same? zuban is strict to error on the 1st
isinstance(val, (float | int))
isinstance(val, float | int)

[kellerza]

sensors = defaultdict[str, dict[str, str]](dict)

error: Argument 1 to "defaultdict" has incompatible type "type[dict]"; expected "Callable[[], dict[str, str]] | None"  [arg-type]

[davidhalter]

Can you make these simpler? This should be a 5 lines reproducer and then errors on the correct lines. In this case I cannot really understand it, because I don't know what line 263 is.

[davidhalter]

The second one is a bug, I just opened an issue for it: #291

Feel free to just report these. I'm happy to fix them if they are bugs.

[davidhalter]

Hi Johann

I have no current plans of supporting attrs, but I would probably look into it in two cases:

1. An open source project of decent size that wants to run Zuban needs this
2. If a company is willing to sponsor work on this I'm happy to do it

I'm aware that Mypy supports this and I have intentionally skipped the attrs related tests for now.

Sorry if this doesn't help you, but it's just not a big priority.

Is there an upside to using attrs vs. dataclasses or do you simply use it, because attrs has been around before dataclasses and it's hard to migrate a bigger code base?

[kellerza]

Looking at this again, with Python 3.13 dataclasses adding support for converters, this might be an option. This was a huge gap. They still don't have validators, but raising an exception in the converter for the few cases I use should be ok.

dataclass support also seems to work well in cattrs for ingesting external data

Thank you!

[kellerza]

Only now saw it was rejected :-(