Make anonymous classes and functions (with name _) reassignable with any type

[Azureblade3808]

Currently, this is allowed --

_ = 0
_ = 0.0
_ = ""

And this is also allowed --

def _() -> None: ...
def _(x: int) -> str: ...

class _: ...

But this is NOT allowed --

_ = 0
def _() -> None: ...

I don't think the logic behind is making sense.

In real code, I have several occations that I like to deploy an anonymous function (e.g. a Qt signal connection) and it conflicts with some anonymous values elsewhere, and anonymous values are not that rare because of "reportUnusedCallResult".

[erictraut]

Pyright distinguishes between symbols with declared types and symbols without declared types. Type declarations come from statements like x: int, y: str = "", def a() -> None: ... or class b: ....

It applies the following rules:

1. If a symbol has a declared type, all assignments to that symbol must conform to that declared type.
2. If a type is declared for a symbol more than once, the declared type must match.

I have already added an exception to rule 2 for you if the symbol is named _. I was very reluctant to do this because the last thing pyright needs is more special casing of rules, and I didn't think the justification here was very strong.

Now you are asking for a special case to rule 1 if the symbol is named _.

I'm more inclined at this point to remove the special case for 2 that I previously added for you. I'm regretting making that change at this point.

I think the correct workaround in your code is to use a name other than _ for the function declaration and then assign it to another symbol that doesn't have a type declaration.

def my_function() -> None: ...
x = my_function
...
x = something_else

[Azureblade3808]

I'm fully supporting you if you are going to revert that change, as current rules about _s are just inconsistent.

But I still don't think naming a fire-and-forget function is a good idea when its functionality can get fully explained elsewhere.

For example --

def __init__(self) -> None:
    @self.view.ok_button.clicked.connect
    def handle_click_on_ok_button() -> None:
        ...

against

def __init__(self) -> None:
    @self.view.ok_button.clicked.connect
    def _() -> None:
        ...

I prefer the latter version, because it will cause less pain when ok_button gets renamed, into submit_button, or the firing condition changes from a click into a double click.

[Azureblade3808]

Ah, I almost forgot that the normal version should be

def __init__(self) -> None:
    def handle_click_on_ok_button() -> None:
        ...

    self.view.ok_button.clicked.connect(handle_click_on_click_button)

or even

def __init__(self) -> None:
    self.view.ok_button.clicked.connect(self.handle_click_on_click_button)

def handle_click_on_ok_button(self) -> None:
    ...

which are both less readable to me, as the event and the handler either are declared in a reversed order in occurence or get separated away.

[Azureblade3808]

If Pyright is not going to support arbitrary assignment for _s, please remove every special rules about _s, including the ones that are allowing declaration of multiple functions and classes all with the name of _ in the same scope.

Then it can be said that _ are only used to store unwanted call results, and there should be no anonymous classes or anonymous functions.

[erictraut]

I think there is still an argument in favor of disabling the reportIncompatibleMethodOverride rule for methods named _. This is commonly used for single dispatch patterns, and there is no good workaround short of completely disabling reportIncompatibleMethodOverride.

But I don't think there's a compelling argument in favor of disabling general type checking rules for cases like this:

_ = 0
def _() -> None: ...

In this case, _ has a declared type (() -> None), and the statement _ = 0 is attempting to assign a value with an incompatible type.

You can avoid this situation with a simple and straightforward workaround.

[Azureblade3808]

So, just because there is a single-dispatching function, using _ to suppress unused result becomes illegal? Especially when it occurs in the global scope?

from functools import singledispatch
from typing import Any

@singledispatch
def func(*args: Any) -> int:
    ...

@func.register(int)
def _(x: int, *args: Any) -> int:
    ...

@func.register(str)
def _(x: str, *args: Any) -> int:
    ...

_ = func()

I think the reason why single-dispatched sub functions get named as _ is not much different than mine. Names here are irrelevant and naming is hard.

[erictraut]

Single dispatch is a common pattern used by many developers. You are arguing for an exemption to a core type checking rule based on a coding pattern and naming convention that you personally want to use, but there is no established convention here. Plus, as I mentioned above, there's a straightforward workaround in this case: use a different symbol name. If you find it difficult to come up with good names, use _1, _2, etc.

The single dispatch pattern doesn't violate the type checking rule that states that a declared type for a symbol must be enforced when a value is assigned to that symbol (what I called "rule 1" above). This fundamental rule is enforced even with basic type checking. The other rule ("rule 2" above) is a strict-mode (more advanced) rule.

[Azureblade3808]

There are already special rules for "_", right? I think these special rules are causing buggy behaviors. For example --

While

def _() -> None: ...
_ = 0

is considered invalid,

def _() -> None: ...
_: int = 0

is considered valid, and

_: int = ""  # ???
_: str = ""

is also considered valid.

If I guess it right, the underlying logic may be like --

if declaredTypeObscurationOccurred():
    if name == "_":
        # Ignore the obscuration.
        pass
    else:
        reportDeclaredTypeObscuration()

and I don't think such logic is healthy.

In my opinion, as long as it is difficult to handle the declared types of "_"s, it is far better just to ignore them at all.

[erictraut]

I agree that these are inconsistent. I've just checked in a change that makes these consistent while preserving the special case for the single dispatch pattern. This will be included in the next release.

[Azureblade3808]

I've found a simpler work-around --

from __future__ import annotations

from typing import Any, Callable, TypeVar

_T = TypeVar("_T")

def retry_until_success(action: Callable[[], _T], /) -> _T:
    while True:
        try:
            return action()
        except:
            continue

@retry_until_success
def _() -> str:
    return ""
str_value = _  # Implicitly typed as 'str' which is expected. Hooray.

def discardable() -> int:
    return 0
_ = discardable()  # Typed as 'Any' instead of 'int', but it should be ignored nevertheless.

@retry_until_success
def _() -> int:
    return 0
int_value: int = _  # No problem with an explicit type.
value_of_wrong_type: str = _  # Found type issue here, as expected.

# Suppressing warnings of assigning incompatible types to '_'.
_: Any

The last line is what accomplishes magic. It overwrites the declared type of '_' as Any, so that any assignment to '_' would be considered valid. And those '_'s declared as decorated functions is treated like they were explicitly typed with the result types, so the types are distinguished, and conflicts among these declared types get tolerated by the 'singledispatch' rule.

This work-around is coupling tightly with internal logic of pyright, but the result is exactly what I need. As long as you have no recent plans of changing how '_'s and declared types work, I will keep on this way.