Preferred way of typing descriptor that can't be accessed on the class

[henribru]

I'm trying to type a descriptor that raises an error when accessed on the class instead of on an instance. Somewhat simplified example:

from typing import TypeVar, Generic

T = TypeVar("T")

class Field(Generic[T]):
    value: T
    
    def __init__(self, value: T) -> None:
        self.value = value
    
    def __get__(self, obj: object | None, owner: type) -> T:
        if obj is None:
            raise AttributeError()
        return self.value

Simply removing None from the signature doesn't work since None is compatible with object anyway, but if the descriptor is only supposed to be used with a certain base class it's possible to substitute in that to reject None. This solution works in my case and works okay in Mypy and Pyright (though the error message isn't the most obvious unless you understand how descriptors work):

https://mypy-play.net/?mypy=latest&python=3.11&gist=03db7ed46920f565c295487e6595e904

https://pyright-play.net/?code=GYJw9gtgBALgngBwJYDsDmUkQWEMoAqiApgGoCGIANFAOLErEhIDGNYAbkwDZjkAmAWABQIglAC8hEhRAAKAEQEFAShEiW3cgGdtUAEI7iALigA6C%2BuGadegGJJi3fnPqNmLANoEAuiuMiUEFQHOTcAK4mhIHBMUH8xMBQAPrJqEgwqXLaTsA0oRFRBCpQALQAfFAAcmCMAcLBjVA53MBmBZGSIWGRcVB9CUmpaMSZydm57ABGAFamhjnsAO7upvAIxJ4LxH5llQT1TcFISWCzmHo1dX1HQSDkSDlQAIIwMMxT4TDEAKIg4PI1A1biBRuEQChmrl2j1iFYbLooHYwGA5Nt-H1yF0HE4XABmIGNKygrhhZLrYhyZFgMzkIEk4hkilUlFyFS0lRAA

If you don't have such a base class, another possibility is to add a overload for the None case that uses NoReturn:

https://mypy-play.net/?mypy=latest&python=3.11&gist=eeeaef24bca109c527630eea10be3134

https://pyright-play.net/?code=GYJw9gtgBALgngBwJYDsDmUkQWEMoAqiApgGoCGIANFAOLErEhIDGNYAbkwDZjkAmNAHJgASsRgBXECgCwAKAUEoAXkIkKIABQAiAjoCUChS27kAzuagAhC8QBcUAHQvj80xasAxJMW78tekZmFgBtAgBdA3sFKDioDnJuSQdCWPj0uP5iYCgAfTzUJBgCrXM-YBpE5NSCAygAWgA%2BKBFGGPl4rqhy7mAnapTVBKSUzKhxgAFOHj5%2BcezcgrQJUt7KqDAAIwArRzbidgB3YMd4BGJ65taxCWkURxcnKZmQXgEFnPy8lZK8soq7F2jm2O2ILBgx1OsBIVxaBEerk68UW31%2Ba0Bm2BWLBEKgAB8bowoUwzrDGvCOt14khcqDMFYDlTqd0QOQkOUoABBGAwZhbSQwYgAURA4G0RmR1JAdxkPQqA1GxDcHksUC8YDAWls5Wi43Iwx8fgCAGZJV03DKuEk8udiFoNWAnORJVbiDa7Q7NVoDM6DEA

A disadvantage of this approach is that it won't error at the attribute lookup site, but at the use site, and the error probably won't be that understandable in this case either.

What I would really like is to get the usual error that the attribute doesn't exist at all (e.g. attr-defined in Mypy). But that's perhaps not possible? Are there any other approaches that might be preferable to my suggestions?

This part isn't directly related to type checking, but would also be nice with a solution which stopped IDEs from autocompleting the attribute on the class. Pylance still does in both cases at least.

[erictraut]

I don't see a better solution than the one you've proposed.

Most descriptors that don't support access through the class return Self rather than raising an exception. That's how property works, for example.

[erictraut]

A function with a NoReturn return type doesn't mean that it isn't callable. It means that if you call it, control won't return to the caller. So I think pylance's current behavior is appropriate here. It shouldn't avoid offering this completion. There was some discussion of providing some other mechanism (a new decorator perhaps?) to specify that an overload, if matched, should be considered a type error, but I can't find the thread at the moment.

As for the popup message in your screen shot, feel free to file a bug in the pylance-release project if you'd like the pylance team to take a look at that.

[AlexWaygood]

There was some discussion of providing some other mechanism (a new decorator perhaps?) to specify that an overload, if matched, should be considered a type error, but I can't find the thread at the moment.

#1043, I think

[erictraut]

Thanks Alex. Yeah, that was the thread I was thinking of. PEP 702 (marking deprecations using the type system) came out of that thread, and this PEP was recently accepted. Pyright and pylance have support for PEP 702. You could mark the first overload as @deprecated.

Pylance doesn't currently filter completion suggestions based on whether they're deprecated, but that's an enhancement that the pylance team might consider. Here is a related feature request.

[henribru]

A function with a NoReturn return type doesn't mean that it isn't callable. It means that if you call it, control won't return to the caller. So I think pylance's current behavior is appropriate here. It shouldn't avoid offering this completion.

Okay, fair enough. What about the first case, where there's no matching signature? It seems somewhat analogous to a simpler case like this, where the attribute access itself is a type error: https://pyright-play.net/?code=GYJw9gtgBALgngBwJYDsDmUkQWEMoAqiApgGoCGIANFAOLErEhIDGAsAFCcFQC8hJCiAAUAIgKiAlJ04sANuQDOiqADEwYYfUbMWAbQIBdSQC5OUC1AAmxYFGAbhi4nOAmoo9WD2oYhqVAAtAB8mCgw7gB00TIcDmAAjHxqGj7hhsLScRoATMleeoowIBlZnCDEAG7E5HIA%2BvAIxMLxCZHxWRXVtQ0kLbntGpJAA

In such cases the completion seems less appropriate? Though it's again pretty niche so perhaps not worth implementing special handling of it.

As for the popup message in your screen shot, feel free to file a bug in the pylance-release project if you'd like the pylance team to take a look at that.

Will do! Sometimes I'm a bit confused about where pyright stops and pylance begins and I get unsure about where I should open an issue, so thanks for pointing me in the right direction.

[erictraut]

Sometimes I'm a bit confused about where pyright stops and pylance begins

No worries. The pylance team generally handles anything related to language server features (like completion suggestions), whereas pyright is focused on type checking features and static analysis. If you're unsure, don't spend too much time thinking about it. Post the issue in either location, and we can easily move issues between projects.