Should a descriptor (with __set__) marked as "final" allow assignments from instances?

[bzoracler]

My intuition is "yes", based on the behaviour of @property (mypy Playground, pyre Playground, Pyright playground):

import typing as t

class A:
    @property
    @t.final
    def prop(self) -> int:
        return 0
    
    @prop.setter
    @t.final
    def prop(self, val: int, /) -> None: ...


a: A = A()
a.prop = 8   # OK
a.prop = ""  # Type error

However, the type-checkers tested above don't seem to support custom final descriptors participating in instance assignments (mypy Playground, pyre Playground, Pyright Playground):

import typing as t

class D:
    def __set__(self, obj: t.Any, val: int, /) -> None: ...

class A:
    desc = D()
    desc_final: t.Final = D()

a: A = A()
a.desc = 8         # OK
a.desc = ""        # Expected type error
a.desc_final = 8   # Type-checkers complain here about assignment
a.desc_final = ""  # Type-checkers complain here about assignment

[Daverball]

This is just completely unspecified behavior. typing.final is not supposed to work with descriptors, only with methods and classes, and indeed mypy complains about it. Extending typing.final to work with property and other decorators that return arbitrary types seems like it could make sense, but there are some nuances about it that make it non-trivial. Namely type checkers disallow assignments to methods, but not necessarily for some of the other types that could be returned by the descriptor.

The behavior with typing.Final makes complete sense, since it always applies to the parent scope, rather than the enclosed type. Changing this behavior based on the RHS seems like a bad idea to me, because what do you with Any?

There will always be some ambiguity about what final exactly means here and what it applies to, but I think the current interpretation is the least likely to cause consistency issues, so I think the only reasonable way to extend typing.final to work with decorators that return arbitrary objects is to make it equivalent to typing.Final i.e. the following two things are equivalent:

class Foo:
    x: Final = desc(lamda: ...)
    @final
    @desc
    def y(self) -> int: ...

Which is not what you want. But I think that if we want to be able to create descriptors that are settable but can't be overridden in subclasses we need a new, separate type qualifier.

[bzoracler]

Changing this behavior based on the RHS seems like a bad idea to me, because what do you with Any?

Thanks for bringing up this up, if you mean the potential of false positives in this situation:

class Foo:
    x: Final[Any] = desc_with__set__()

foo: Foo = Foo()
foo.x = 1  # Should this be a type-checker error?

Final here is not the main issue - rather, it is the appearance of x marked explicitly as a class-scoped variable, so x: ClassVar[Any] would suffer the same potential ambiguity. Pyright handles this by indeed marking the assignment as an error (see Pyright Playground example, also microsoft/pyright#4837).

I agree with the way Pyright handles this. My interpretation is that Any is only concerned with type compatibility, not scope compatibility. Without knowledge of what Foo.x is, foo.x should be interpreted as an instance-level assignment, and I think it is out-of-scope (!) for a class-scoped Any to consider assignment compatibility at the instance level. In this example, then, a class-scoped Any should not widen the possibility of the instance-level foo.x = 1 to be interpreted as type(foo).x.__set__(foo, 1), and foo.x = 1 should be continued (as currently) to be treated as an error.

If Any is the only ambiguous factor here, I don't think this is necessary:

... I think that if we want to be able to create descriptors that are settable but can't be overridden in subclasses we need a new, separate type qualifier.

[Daverball]

Making Final/ClassVar only apply to the class level depending on whether or not that specific attribute contains a descriptor or not contradicts the documentation and its behavior is currently not explicitly specified in the typing spec, so I think you will need to open a discussion at https://discuss.python.org/ and subsequently create pull request here that amends the typing spec accordingly, if you want to change what type checkers do here.

I'm worried about adding another layer of confusion on top of mutability vs. assignability with descriptors having their own rules. I'd rather make the type system more expressive here, so each case can be covered unambiguously, even if there is a case to be made for special-casing descriptors.

See the README here for a concrete list of steps to follow: https://github.com/python/typing-council