`Unexpected argument` warnings in Pycharm for `@define`-derived syntax
Thanks for maintaining attrs π I was hoping to start using the newer syntax in a project, but ran into a tiny issue:
Code sample
import attr
@attr.s
class A:
a: str
b: int
c: bool
@classmethod
def from_method(cls, a, b, c):
return cls(a=a, b=b, c=c)
@attr.define
class B:
a: str
b: int
c: bool
@classmethod
def from_method(cls, a, b, c):
return cls(a=a, b=b, c=c)
What happens
For attrs.define, attrs.frozen, attrs.mutable, etc. all trigger IDE warnings in Pycharm.
Do you have any idea what the issue might be here? I tried looking at the stubs Pycharm uses, but wasn't able to find any obvious differences that would explain this.
I would imagine it's an issue on their end. Does it also happens when you use attrs.define (as opposed to attr)?
The issue persists for both import paths, unfortunately
Please, please, please report this to PyCharm, or upvote a potentially existing bug (I think we already had a similar bug here). They tend to be customer-oriented so this is our best chance.
Before I do, just to eliminate the possibility of long unnecessary waits for several parties: do you not know of any difference between define and attrs decorators that could explain this? There's no dynamic argument recognition based on default properties that Pycharm might be inferring correctly?
If not, I'd be happy to report it there and link it back to this discussion.
There's https://peps.python.org/pep-0681/, which we do support both for attr.s and define.
Yeah it's important to remember that the interference of what an attrs (or dataclass)-decorated class looks like does not come from the type stubs. The type checkers have to implement their own support. PyCharm added direct support quite early, Mypy has a separate plugin.
PEP 681 that Tin mentioned is supposed to fix that, although a lot of that is the lowest common denominator. But it's better than nothing.
Thanks for the quick responses. I'll open an issue in the Pycharm bug tracker when I get a chance and link to it here.
Would it make sense to keep this issue open in the meantime, or would you prefer closing it?
I guess we can leave one open so people don't open more issues.
Also: @pauleveritt my heart is broken by your lack of love. ;) Pls poke around? π₯ΊπΆ
I added a comment to https://youtrack.jetbrains.com/issue/PY-47532/Suuport-new-attrs-aliases, since this ticket seems to be pretty closely related π
@hynek Customer oriented but PyCon hungover. I'll post something in our Slack now.
There's nothing we can do her β let's pray to the Kanban gods.