gh-89547: Support for nesting special forms like Final #116096
Conversation
|
All commit authors signed the Contributor License Agreement. |
There was a problem hiding this comment.
Wow, that's an easy change to make! Not sure if we want to treat this as a new feature or a backportable bugfix — thoughts, @JelleZijlstra?
|
@JelleZijlstra what do you see as the risk of backporting? It seems like arguably a "bug" that (given the current de facto behavior of type checkers) there is no way to specify a Final, non-field, ClassVar, on a dataclass. Backporting this would fix that "bug" for all users of Python 3.11 and Python 3.12, rather than requiring they wait until 3.13. |
|
It feels like a new feature to me; we're adding support for something that wasn't previously allowed. For example, if a library after the release of 3.12.3 starts using Users on earlier versions can work around the problem by using quoted annotations. |
This still needs to be done |
|
Thanks, done in #116686 |
Resolves this issue. The main goal was to permit
ClassVar[Final[int]]andFinal[ClassVar[int]]. This drops validation check that Final/ClassVar argument is not a special form.This does allow some silly cases like
ClassVar[ClassVar[int]]but I think it's simpler to allow them then have more complex validation rules at runtime. I did not remove special form check for other forms soUnion[ClassVar[int], int]remains forbidden andlist[ClassVar[int]]is also forbidden. There already was a test case thatlist[ClassVar[int]]fails.I also added couple tests for Annotated to ensure it can nest freely with
ClassVar/Final.