PEP 702 (@deprecated): "normal" overloaded methods

[tyralla]

Fixes #18474

It seems I covered overloaded functions, descriptors, and special methods so far but completely forgot about "normal" methods (thanks to @sobolevn for pointing this out). This addition should do the trick.

[sobolevn]

Thanks! What about @staticmethod and @classmethod?

[sobolevn]

Suggested change

	(node is None)
	and (member is not None)
	and isinstance(object_type, Instance)
	and ((symbol := object_type.type.names.get(member)) is not None)
	node is None
	and member is not None
	and isinstance(object_type, Instance)
	and (symbol := object_type.type.names.get(member)) is not None

[tyralla]

I will have a look at it later.

[tyralla]

It became a one-liner followed by a loop.

[tyralla]

Inheritance is also an issue: If the (overloaded) function is defined by a base class of object_type, object_type.type.names.get(member) cannot work.

The base class is not directly available. Going through the MRO might be necessary (at least for static methods).

[tyralla]

@sobolevn: classmethod already worked, staticmethod not (needed to skip bind_self). Inheritance now also works. Searching through the MRO makes it even nastier, in my opinion, but I found no other place where all information is directly available.

[sobolevn]

Thanks! Just two minor nitpicks :)

[sobolevn]

I would also test this case:

Suggested change

	a.f("x")
	a.f("x")
	int_or_str: Union[int, str]
	a.f(int_or_str)

It should not raise if all is good.

[tyralla]

It does not raise a warning, but why do you think it should not?

(There is not even a warning for a.h, where the implementation is marked as deprecated, which is inconsistent with how functions are handled.)

[tyralla]

(There is not even a warning for a.h, where the implementation is marked as deprecated, which is inconsistent with how functions are handled.)

I made it consistent in c95f936. However, I added the in my opinion missing warnings to the test case, to prevent us from merging this too early by accident. I am curious to hear why you think the current behaviour is correct. (regarding int_or_str).

[sobolevn]

There's a failing test now, please take a look. From the brief looks it is related to the Union type change.

It is unspecified in https://typing.readthedocs.io/en/latest/spec/directives.html#deprecated so we can ping @JelleZijlstra to see if that is correct.

[tyralla]

Yes, the test now fails intentionally (as written somewhere above). I will wait for Jelle's response and adjust either warn_deprecated_overload_item or the TestDeprecatedOverloadedInstanceMethods test case afterwards

[hauntsaninja]

I think it would make sense to issue the warning for the union, since that's the "sound" thing to do. I also checked against pyanalyze and pyright (since they were the reference impl's for PEP 702) and both of them issue a warning. pyanalyze is by Jelle, so that's probably his opinion on this

(If we do this, we should also add a test case for overloaded functions — mypy doesn't currently complain about passing a union that matches a deprecated overload and whatever we decide to do, we should be consistent)

[JelleZijlstra]

Just so I understand correctly, the question is about whether code like this should warn about the deprecation:

from typing import overload
from warnings import deprecated


@overload
@deprecated("use str")
def f(x: int) -> str: ...
@overload
def f(x: str) -> str: ...
def f(x: int | str) -> str:
    return str(x)

def caller(x: int | str):
    f(x)

And my answer is yes (as Shantanu surmised above). My rule of thumb is: if there would be an error if the deprecation was carried out (i.e., the int overload was removed), then there should be a deprecation warning now.

[tyralla]

Thank you very much for sharing your opinions on this. I will adjust warn_deprecated_overload_item tomorrow and add corresponding test cases for overloaded functions and descriptors.

[tyralla]

Hmm, things are a little different (and eventually more complicated) than I expected. I have to study the responses of check_overload_call in more detail to (hopefully) cover all possible cases. I removed the int_or_str tests so that we do not mix-up things and the current state can be merged (according the the first review) as is (and eventually be cherry-picked into Mypy 1.15?).

I hope to propose a fix for Unions in the next few days.

[hauntsaninja]

nit: I think we can use object_type.type.get(member)

[tyralla]

You're right, I adjusted it.

[github-actions]

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

[sobolevn]

Thank you! Let's continue the Union work in the next PR.