Fix/attrs init overload

[uko3211]

Fixes #19003

This PR fixes the issue by handling the case where the init method can be an OverloadedFuncDef with CallableType items.

[sterliakov]

I'm afraid this will break horribly down the road. Any custom __init__ method is a disaster for this plugin, note how we use its arg_names and arg_types to get the actual field types. If __init__ method is customized, this is no longer true, and _get_expanded_attr_types will no longer be correct. I'd suggest just failing with a different error ("overridden init not supported" instead of "not an attrs class"), but also feel free to explore alternative ways to gather fields!

To see this actually causing trouble (maybe I'm reading the code wrong, after all), please try adding a testcase with such overridden __init__ where arg names/types do not correspond to the generated signature and using attrs.evolve on that class.

[uko3211]

Hello! First of all, thank you for your detailed comment. From what I understand, I don’t believe there’s anything wrong with the code I wrote to address the issue. However, based on your feedback, it seems you’re suggesting that instead of returning None, it would be better to explicitly fail when a custom init is detected—something like:
raise TypeError("Custom __init__ methods are not supported with this plugin")
Is that correct?

(This is my first PR, and English is not my first language, so I really appreciate your understanding in case I misunderstood anything)

[sterliakov]

Huh, not exactly, raising a TypeError is a bit too harsh: mypy reports errors differently, we do not make it crash when a problem is detected in user's code. Look at how _fail_not_attrs_class function reports the problem - I suspect you need to do something similar based on ctx.api.fail.

However, on second thought we usually avoid producing error messages when some construct is not supported or cannot be expressed statically. It might be wiser to fall back to Any in that case and accept the call as-is, even if the arguments do not match. I'm not sure which of the options is better.

To explain my point about "potential problems" caused by overloaded or even just manually defined __init__, here are two snippets:

from typing import overload

import attrs

@attrs.frozen(init=False)
class C:
    x: "int | str"

    @overload
    def __init__(self, x: int) -> None: ...

    @overload
    def __init__(self, x: str) -> None: ...

    def __init__(self, x: "int | str") -> None:
        self.__attrs_init__(x)


obj = C(1)
attrs.evolve(obj, x=2)
attrs.evolve(obj, x="2")  # E: ... - False positive

import attrs

@attrs.frozen(init=False)
class C:
    x: "int | str"

    def __init__(self, x: "int | str", y: bool) -> None:
        self.__attrs_init__(x)


obj = C(1, False)
attrs.evolve(obj, x=2)  # False negative, error at runtime

[uko3211]

Thank you so much for the detailed explanation. It was really helpful and I believe it will greatly assist me in resolving the issue.

Among the approaches you suggested, I feel that using ctx.api.fail might actually introduce unnecessary limitations for mypy users. So I think falling back to Any, as you mentioned, would be a better solution in this case.

I'll revise the code accordingly and push the changes soon.

[uko3211]

1. The overloaded custom init no longer returns an error.
2. The ambiguous type in the overloaded custom init is handled by returning any, allowing users to proceed with awareness of this behavior.

[uko3211]

I understand you may be busy, but I would really appreciate it if you could take a moment to review my latest commit. Thank you!
@sterliakov

[sterliakov]

I'm not sure I love the idea of returning AnyType, that seems a bit arbitrary, but should work at least. Please add relevant testcases - see test-data/unit/check-plugin-attrs.test for inspiring examples, you'll just need to add new testcases with snippets that fail before this patch and work now (and try to think of as many corner cases as you can) to that file. Note the [builtins fixtures/plugin_attrs.pyi] line at the bottom of every testcase, you'll need to add it to new tests as well (or you may see weird errors about undefined builtin names).

[uko3211]

Thank you for the review. I will update and upload the test cases within today. Have a great day :)

[uko3211]

@sterliakov Hello, After several attempts, I was able to add the test case.
I would appreciate it if you could review it carefully.
Have a great day!

[uko3211]

Diff from mypy_primer, showing the effect of this PR on open source code:

xarray (https://github.com/pydata/xarray)
+ xarray/conventions.py:413: error: Argument "decode_timedelta" to "decode_cf_variable" has incompatible type "object"; expected "bool | CFTimedeltaCoder | None"  [arg-type]

After I committed the changes to attrs.py, there were no issues reported by mypy_primer. However, the error appeared only after I committed the test cases. Based on this, I believe it might be a false positive.

When comparing the importance of mypy issue #19003 with the reported error in xarray, I think resolving issue #19003 should take priority and is more critical at this point.

If it turns out that the error reported in xarray is actually a valid detection — due to an argument not matching the expected type — then after this PR is merged, I will either modify the xarray source code to ignore the case where the function receives an object type, or open an issue in the xarray repository to address it.

All in all, it seems that the error is an expected outcome of the changes made in this PR, and I believe it's something that should be fixed within the xarray project

[sterliakov]

Ignore the xarray diff, we have some recent regression causing nondeterministic results to appear more often, tracked in #19121. The xarray diff was reported on even more obviously unrelated PRs, don't ping its maintainers - this is a mypy bug.

[uko3211]

@sterliakov Hello,
I've completed the updates to both the test-case and attrs.py files. All the changes are intentional and the tests have been updated accordingly.

However, I'm now seeing an error from the GitHub bot that wasn't occurring before. From my investigation, this issue doesn’t appear to be caused by my changes. Could you please help verify whether this is a problem with the bot or something unrelated to my patch?

[sterliakov]

The xarray issue is moot, while the test failures are real - the changed code does not pass some tests. Either the __init__ method is somehow not plugin_generated (which is a bug) or something went wrong in this PR.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[uko3211]

@sterliakov Hi, the updated changes are now working correctly. Could you please review my PR to see if it’s ready to be merged?

[uko3211]

Hello! I haven't received a response regarding my recent commits for a few days, so I just wanted to send a quick ping. Apologies for bothering you during your busy schedule! @sterliakov @JukkaL

[sterliakov]

Apologies for any confusion I might have caused by my previous comment, but by saying that " it should be looked up on a different object" I didn't mean defining it on another node in addition...

[sterliakov]

typ.type.get returns a SymbolTableNode that already has plugin_generated attribute. get_method is a higher-level wrapper that returns a function. I'd probably do something like

Suggested change

	if init_method.plugin_generated:
	init_node = typ.type.get("__init__") or typ.type.get(ATTRS_INIT_NAME)
	if init_node.plugin_generated:

and then it won't be necessary to propagate that attribute down to FuncDef. This function isn't hot (this part is only reached when we have evolve call on some actual attrs class), so we can afford simply looking up twice to avoid uwrapping init_node manually.

[uko3211]

I'll update that part using the approach you recommended! (I expect to make the changes and push them within a day or two.)
Is there anything else I should take care of?
This is my first time contributing to mypy, so I know there were some shortcomings.
Thank you so much for your kind and thorough support :)

[uko3211]

If there are no additional requests, do you think this PR could be ready for merging?
I’d appreciate any feedback you might have.