Shouldn't this be

It's valid to do PhysicalType() == 4, which will return False after trying 4.__req__().

Unresolving this, since I think @eerovaher's comment is actually relevant: isn't typing supposed to tell what is needed to make this function succeed? With PhysicalType|str, that is clear, with object you get zero information.

I guess for these dunder methods, it depends on what you mean by "succeed" - I'd argue that returning NotImplemented is a form of not succeeding, since if the reverse also does it, you get a TypeError. More generally, that the reverse is called is irrelevant for thinking about success of this function.

See https://discuss.python.org/t/make-type-hints-for-eq-of-primitives-less-strict/34240/10 for a discussion where people are advocating for making typing dunder methods less strict. The typing of most dunder methods is limited by inheritance from "object". Currently the correct annotation for equality is __eq__(self, other: object) -> bool. Not annotating the return type of NotImplemented is problematic but baked into Python ATM. Accepting any input is correct since evaluating an equality to False is a valid output, even if it happens from a double NotImplemented behind-the-scenes.

Having other be restricted only makes sense if the method errors or doesn't work on that input. __eq__ et al work, returning NotImplemented / False.

I understand the logic, but it is not a useful one to humans or much in the spirit of what NotImplemented means - I'd say we don't annotate these until the discussion has concluded.

this is a good place for typing.overload.

Same comment as for __eq__ - I think we'd want the type information to tell what gives success, not what gives failure, where for this function failure means getting NotImplemented.

Note that I really worry about "this is a good place for typing.overload - if we are adding more than annotations, suddenly files can become like this

    # Builtin types
    @overload
    def __new__(cls, dtype: type[builtins.bool], align: builtins.bool = ..., copy: builtins.bool = ..., metadata: dict[builtins.str, Any] = ...) -> dtype[np.bool]: ...
    @overload
    def __new__(cls, dtype: type[int], align: builtins.bool = ..., copy: builtins.bool = ..., metadata: dict[builtins.str, Any] = ...) -> dtype[int_]: ...
    @overload
    def __new__(cls, dtype: None | type[float], align: builtins.bool = ..., copy: builtins.bool = ..., metadata: dict[builtins.str, Any] = ...) -> dtype[float64]: ...
    @overload
    def __new__(cls, dtype: type[complex], align: builtins.bool = ..., copy: builtins.bool = ..., metadata: dict[builtins.str, Any] = ...) -> dtype[complex128]: ...
    @overload
    def __new__(cls, dtype: type[builtins.str], align: builtins.bool = ..., copy: builtins.bool = ..., metadata: dict[builtins.str, Any] = ...) -> dtype[str_]: ...
    @overload
    def __new__(cls, dtype: type[bytes], align: builtins.bool = ..., copy: builtins.bool = ..., metadata: dict[builtins.str, Any] = ...) -> dtype[bytes_]: ...

Can we pretty please agree that overload has no place in regular python code files?

The standard is actually to not put NotImplemented into the type hint of dunder methods.

Bit of a flyby, as I was just looking how the typing "looks": these ones seem rather superfluous; are there not some standard defaults for dunder operations like these?

@mhvk — that is a great question that I do not know the answer to! I think that static type checkers like mypy still need type hints in order to check dunder methods, but I'm not sure.

When adding type hints to plasmapy.particles, I was able to use autotyping to automatically add type hints for dunder methods, which was pretty straightforward.

See comment about __eq__ - it seems much more logical to me to put here things that allow __mul__ to succeed.

Seems good to have QuantityLike and PhysicalTypeLike defined, use it here.

👍 on using a type alias PhysicalTypeLike. This is again driven by use of type annotations as developer docs, not trying to please mypy. Whether PhysicalTypeLike tries to enumerate all the possibilities or if it is just an empty type alias makes no difference to me, but seeing that while developing code is very useful.

Indeed, and I like that those can be stored in a types.py file, so one can fiddle with those definitions without having to change how the code itself looks.

Why does this need an annotation?