Carl Meyer <c...@oddbird.net> 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 should not be made, and the inconsistency with PEP 591 should
rather be resolved by explicitly specifying the interaction with dataclasses in
a modification to the PEP.
Currently the meaning of:
```
@dataclass
class C:
x: Final[int] = 3
```
is well-defined, intuitive, and implemented consistently both in the runtime
and in type checkers. It specifies a dataclass field of type `int`, with a
default value of `3` for new instances, which can be overridden with an init
arg, but cannot be modified (per type checker; runtime doesn't enforce Final)
after the instance is initialized.
Changing the meaning of the above code to be "a dataclass with no fields, but
one final class attribute of value 3" is a backwards-incompatible change to a
less useful and less intuitive behavior.
I argue the current behavior is intuitive because in general the type
annotation on a dataclass attribute applies to the eventual instance attribute,
not to the immediate RHS -- this is made very clear by the fact that
typecheckers happily accept `x: int = dataclasses.field(...)` which in a
non-dataclass context would be a type error. Therefore the Final should
similarly be taken to apply to the eventual instance attribute, not to the
immediate assignment. And therefore it should not (in the case of dataclasses)
imply ClassVar.
I realize that this means that if we want to allow final class attributes on
dataclasses, it would require wrapping an explicit ClassVar around Final, which
violates the current text of PEP 591. I would suggest this is simply because
that PEP did not consider the specific case of dataclasses, and the PEP should
be amended to carve out dataclasses specifically.
----------
nosy: +carljm
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue45384>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
