[issue45384] Accept Final as indicating ClassVar for dataclass

Mehdi2277 added the comment: I recently hit this issue working on a config/parsing runtime type checking library (similar in spirit to pydantic). The one other special typeform I was using these with that led me to discover this issue was Annotated. I use Annotated a fair amount to do some r

[issue45384] Accept Final as indicating ClassVar for dataclass

Gregory Beauregard added the comment: Hi Michael, Thanks for taking the time to look into this. I don't feel strongly enough about following the existing PEP wording to desire creating a situation where instance vars can't be marked Final if we can instead make a workaround with ClassVar[Fi

[issue45384] Accept Final as indicating ClassVar for dataclass

Michael Sullivan added the comment: I tend to agree with Carl that making Final imply ClassVar for dataclass would make things worse. For better or worse (mostly better, but there are downsides like this!), dataclass class bodies are essentially written in their own domain specific language

[issue45384] Accept Final as indicating ClassVar for dataclass

Carl Meyer added the comment: Good idea to check with the PEP authors. I don’t think allowing both ClassVar and Final in dataclasses requires general intersection types. Neither ClassVar nor Final are real types; they aren’t part of the type of the value. They are more like special annotati

[issue45384] Accept Final as indicating ClassVar for dataclass

Gregory Beauregard added the comment: Thanks for the feedback Carl. Your proposed nesting PEP change is not possible: ClassVar[Final[int]] isn't valid because Final[int] isn't a type. As far as I know this would need type intersections to be possible. I'm going to try sending a one-off emai

[issue45384] Accept Final as indicating ClassVar for dataclass

Carl Meyer added the comment: > Are Final default_factory fields real fields or pseudo-fields? (i.e. are they > returned by dataclasses.fields()?) They are real fields, returned by `dataclasses.fields()`. In my opinion, the behavior change proposed in this bug is a bad idea all around, and

[issue45384] Accept Final as indicating ClassVar for dataclass

Gregory Beauregard added the comment: Yeah, I was just discussing this with someone in IRC, and I appreciate an example of it in the wild. I agree there's some wiggle room with what "initialized in a class body" means when it comes to dataclasses. I see several interpretations there, and I

[issue45384] Accept Final as indicating ClassVar for dataclass

Saaket Prakash added the comment: Treating Final as ClassVar by default may be fine, but it should not throw when using default_factory like ClassVar does. There are valid uses of Final with instance variable when one would want the value to be unchanged after the `__init__` runs but differen

[issue45384] Accept Final as indicating ClassVar for dataclass

Gregory Beauregard added the comment: When I originally submitted the issue I hadn't finished going through all of the dataclasses code and it hadn't even occurred to me that it could be valid to use ClassVar with field(). I (wrongly) assumed this would always raise and that field() is only

[issue45384] Accept Final as indicating ClassVar for dataclass

Eric V. Smith added the comment: I was waiting for someone smarter than me to chime in on one of the discussions. I wouldn't worry about whether it's a bug or feature, at this point. Assuming buy-in from type checkers, I'd probably call it a bug, but I can be reasoned with. One thing I don'

[issue45384] Accept Final as indicating ClassVar for dataclass

Gregory Beauregard added the comment: Hi Eric, I've been shopping this idea around on the mailing list and haven't received any objections. Do you have any concerns? Can we handle Final with the same checks as ClassVar? Regarding potentially merging a change, I'm not sure where this falls b

[issue45384] Accept Final as indicating ClassVar for dataclass

Change by Eric V. Smith : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue45384] Accept Final as indicating ClassVar for dataclass

Change by Gregory Beauregard : -- type: enhancement -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue45384] Accept Final as indicating ClassVar for dataclass

New submission from Gregory Beauregard : PEP 591 for the Final Attribute states "Type checkers should infer a final attribute that is initialized in a class body as being a class variable. Variables should not be annotated with both ClassVar and Final." This is a bit of a typing conflict for