classification
Title: Support immutability per-field in dataclasses
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: eric.smith Nosy List: Daniel Lindeman, eric.smith
Priority: normal Keywords:

Created on 2018-05-12 21:28 by Daniel Lindeman, last changed 2018-05-15 04:20 by Daniel Lindeman.

Messages (3)
msg316438 - (view) Author: Daniel Lindeman (Daniel Lindeman) Date: 2018-05-12 21:28
Currently, all fields in dataclasses can be frozen by passing frozen=True to the decorator. There are cases where it would be useful to have some fields be mutable, and others immutable. By using a strategy similar to how the decorator frozen works, using __setattr__ and __delattr__, it would be possible to support immutability per-field. This could perhaps be done by adding a frozen argument to the field constructor.
msg316458 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2018-05-13 10:34
Can you explain your use case for this?

Also, how do you envision this working with the existing frozen, hashing, and equality behavior? There are a lot of interactions there, and we'd want to do something that makes sense holistically, and isn't likely to cause trouble for casual users.

I haven't checked, but does attrs do anything like this? It might make sense to try out the idea there, first.
msg316619 - (view) Author: Daniel Lindeman (Daniel Lindeman) Date: 2018-05-15 04:20
A possible use case would be a field that represents an auto-incrementing database ID. Since the field is auto-incrementing in the database, it would be desirable to keep this field frozen, and others mutable once an instance of a data class is created. 

This is also a feature of data classes in other languages, for example Kotlin: https://kotlinlang.org/docs/reference/data-classes.html . The main difference here being that we don't have val and var, and thus mutability and immutability are harder to represent.

Hashing could be implemented such that frozen fields are allowed to be part of the hash, but unfrozen fields would remain only part of the hash when unsafe_hash is set. I believe equality follows from hashing, so the same rules should apply. 

The conflict between setting the class to frozen, and a field to not frozen could be solved by raising an exception.

Upon investigation, attrs does not support this behavior. I can try this feature with attrs, but their implementation may differ enough to make it infeasible.
History
Date User Action Args
2018-05-15 04:20:40Daniel Lindemansetmessages: + msg316619
2018-05-13 10:34:45eric.smithsetmessages: + msg316458
2018-05-13 05:09:54rhettingersetassignee: eric.smith
components: + Library (Lib)
versions: + Python 3.8, - Python 3.7
2018-05-12 21:28:57Daniel Lindemancreate