[Python-Dev] Should the dataclass frozen property apply to subclasses?

Eric V. Smith eric at trueblade.com
Thu Mar 1 01:43:10 EST 2018


On 3/1/2018 1:02 AM, Nick Coghlan wrote:
> I'm assuming you meant "3.7.0b2" here (and similarly alpha->beta for the 
> other version numbers below)

Oops, yes. Thanks.

>     So going back to original questions above, my suggestions are:
> 
>     1. What happens when a frozen dataclass inherits from a non-frozen
>     dataclass? The result is a frozen dataclass, and all fields are
>     non-writable. No non-fields can be added. This is a reversion to the
>     3.7.0a1 behavior.
> 
>     2. What happens when a non-frozen dataclass inherits from a frozen
>     dataclass? The result is a frozen dataclass, and all fields are
>     non-writable. No non-fields can be added. This is a reversion to the
>     3.7.0a1 behavior. I'd also be okay with this case being an error,
>     and you'd have to explicitly mark the derived class as frozen. This
>     is the 3.7.0a2 behavior.
> 
>     3. What happens when a non-dataclass inherits from a frozen
>     dataclass? The fields that are in the dataclass are non-writable,
>     but new non-field attributes can be added. This is new behavior.
> 
>     4. Can new non-field attributes be created for frozen dataclasses?
>     No. This is existing behavior.
> 
> 
> +1 from me for the variant of this where dataclasses inheriting from 
> frozen data classes must explicitly mark themselves as frozen (at least 
> for now). That way we leave the door open to allowing a variant where a 
> non-frozen dataclass that inherits from a frozen dataclass can set 
> "hash=False" on all of the new fields it adds to avoid becoming frozen 
> itself.

I tend to agree. It's not like this is a huge burden, and at least the 
author is acknowledging that the class will end up frozen.

> 
>     I'm hoping this change isn't so large that we can't get it in to
>     3.7.0a3 next month.
> 
> 
> I think this qualifies as the beta period serving its intended purpose 
> (i.e. reviewing and refining the behaviour of already added features, 
> without allowing completely new features).

Thanks.

Eric



More information about the Python-Dev mailing list