NotificationsYou must be signed in to change notification settings
Fork32.4k
Star67.9k

gh-89547: Support for nesting special forms like Final#116096

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Jump to bottom

Merged

JelleZijlstra merged 2 commits intopython:mainfromhmc-cs-mdrissi:support_nesting_special_forms

Mar 12, 2024

Merged

gh-89547: Support for nesting special forms like Final#116096

JelleZijlstra merged 2 commits intopython:mainfromhmc-cs-mdrissi:support_nesting_special_forms

Mar 12, 2024

Conversation

Copy link

Contributor

hmc-cs-mdrissi commentedFeb 29, 2024•
edited by bedevere-appbot
Loading

Resolves thisissue. The main goal was to permitClassVar[Final[int]] andFinal[ClassVar[int]]. This drops validation check that Final/ClassVar argument is not a special form.

This does allow some silly cases likeClassVar[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 withClassVar/Final.

Issue:Clarify meaning of Final in dataclasses #89547

Add support for nesting special forms like Final

a7ca1f7

hmc-cs-mdrissi requested review fromJelleZijlstra andAlexWaygood ascode owners

February 29, 2024 04:11

Copy link

ghost commentedFeb 29, 2024•
edited by ghost
Loading

All commit authors signed the Contributor License Agreement.

bedevere-appbot added the awaiting review label

Feb 29, 2024

bedevere-appbot mentioned this pull request

Feb 29, 2024

Clarify meaning of Final in dataclasses#89547

Open

Eclips4 added the topic-typing label

Feb 29, 2024

AlexWaygood reviewed

Feb 29, 2024

View reviewed changes

Copy link

Member

AlexWaygood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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?

Lib/test/test_typing.pyShow resolvedHide resolved

Add comment for special forms test

378aaea

JelleZijlstra reviewed

Mar 1, 2024

View reviewed changes

Copy link

Member

JelleZijlstra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Thanks. I feel this should be treated as a new feature and not backported.

It's probably worth aversionchanged note in the typing docs, e.g. saying "ClassVar can now be nested inside Final".

Copy link

Member

carljm commentedMar 1, 2024

@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.

Copy link

Member

JelleZijlstra commentedMar 1, 2024

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 usingClassVar[Final...] in its code and tests only on 3.12.3+, they would break all users who are still on 3.12.2 without realizing it.

Users on earlier versions can work around the problem by using quoted annotations.