Closed alwaysmpe closed 1 month ago
This seems like a pretty obscure edge case, and this is a false negative rather than a false positive, so that makes it less important from my perspective.
For what it's worth, mypy doesn't support this either.
I'm also not convinced that your sample would be the right way to code this. You've provided an overload for Int.__get__
that accepts None
for the obj
parameter. This overload has an annotated type of NoReturn
, but that doesn't mean this isn't callable. It simply means that the call doesn't return control back to the caller. I don't think there are any other places in the typing spec or in pyright's logic where a NoReturn
type specifically means "raises an exception". It would be better to not provide this overload if you want to indicate that this method isn't callable with a None
argument.
For now, I'm going to reject the enhancement request, but I'd reconsider this decision in the future if there's signal from other pyright users that it's something they'd like to see.
Pyright currently supports descriptor types but the init signature of dataclasses with descriptor fields aren't always consistent with the documented behaviour. In particular, if a descriptor's
__get__
method raises anAttributeError
if the passed object isNone
, the dataclass's constructor requires a value, but pyright doesn't currently support this. A simple example:Is your feature request related to a problem? Please describe.
What I'm actually using this for is a parser that's streaming data and optionally caching values parsed from that data and clearing the cache when an index is incremented. The index is the descriptor-typed field, other property functions are wrapped using a decorator provided by the descriptor-typed field. This is a different use case to
functools.lru_cache
.