classification
Title: Define instance mutability explicitly on type objects?
Type: enhancement Stage:
Components: Interpreter Core Versions: Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, eltoder, eric.snow, ncoghlan, njs, rhettinger, trent
Priority: normal Keywords:

Created on 2015-09-03 06:08 by ncoghlan, last changed 2017-12-25 23:58 by ncoghlan.

Messages (7)
msg249605 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2015-09-03 06:08
Issue #24912 showed that the interpreter has historically assumed that all instances of non-heap types are immutable when it comes to preventing __class__ reassignment, and changing this assumption caused problems with genuinely immutable types that use implicit instance caching (like string interning and the small integrer cache).

More generally, whether or not type instances are mutable or not has been defined somewhat informally - decimal.Decimal instances, for example, are nominally immutable, but this immutability is only by convention, rather than enforced by the interpreter.

It may be desirable to be able to explicitly declare instances of a type as mutable or immutable (both from Python and from C), rather than having that property be inferred from other characteristics in a situational way.
msg249612 - (view) Author: Nathaniel Smith (njs) * (Python committer) Date: 2015-09-03 07:28
Adding Eric Snow to nosy because it seems like there may be some natural overlap between this and the per-subinterpreter GIL ideas he brought up on python-ideas back in June.
msg249706 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2015-09-04 02:27
Yeah, this definitely relates to the project I'm working on.
msg250289 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2015-09-09 06:14
Also adding Trent Nelson to the nosy list, as I believe this capability could potentially be relevant to PyParallel.

The reason I say that is that if instance mutability (or the lack thereof) becomes a first class language concept, then we may be able to adopt a Rust style model where mutability can be made *thread relative*.

Thread relative immutability would be trickier than global immutability, but hopefully still feasible.
msg307934 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2017-12-10 00:27
I updated some of the issue metadata and added a question mark to the issue title to help make it clearer that this would require a PEP level conceptual enhancement to the language, rather than being about documenting an existing concept.

PEP 557's data classes take a step in that direction with their "frozen=True" parameter: https://www.python.org/dev/peps/pep-0557/#frozen-instances
msg307971 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-12-10 19:08
I think this is a hazardous path that should be avoided.  Mutability is an elusive concept that is hard to pin down.

Files are immutable when opened in a read-only mode and mutable if opened in a write mode.  Tuples are immutable but may contain mutable elements.  Tuples are immutable to Python programmers but fully mutable to C programmers.  Some objects have some fields than can be mutated and some that can't.  Regular Python classes are always mutable in the sense that there is usually some path to changing almost everything even if __setattr__ has been overridden.  It is more a matter of convention (public API) than a technical point.

I prefer that Python be left as a "consenting adults" language rather than go down this precarious path.  For comparison, think about the issue of constants in Python.  A constant is just a variable that by convention you don't change.  It isn't declared or enforced, yet for the most part this is just fine.
msg309047 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2017-12-25 23:58
Declaring "I intend for instances of this class to be immutable" isn't a fuzzy concept - it's in the same vein as other type hints, like "I intend for this to be a string". The part that's fuzzy is how well Python actually enforces that declaration, and hence the degree to which you can actually rely on it at runtime.

In most cases, detecting and reporting *violations* of that intent would be in the realm of typecheckers rather than the language interpeter, but there'd be cases where the interpreter itself could make useful inferences from such a declaration (for example, by prohibiting conventional mutation operations, the way "frozen=True" does for data classes).
History
Date User Action Args
2017-12-25 23:58:24ncoghlansetmessages: + msg309047
2017-12-11 04:26:50rhettingersetassignee: rhettinger ->
2017-12-10 19:08:38rhettingersetassignee: rhettinger

messages: + msg307971
nosy: + rhettinger
2017-12-10 00:27:44ncoghlansetversions: + Python 3.8, - Python 3.6
title: Define instance mutability explicitly on type objects -> Define instance mutability explicitly on type objects?
messages: + msg307934

components: + Interpreter Core
type: enhancement
2015-09-09 06:14:32ncoghlansetnosy: + trent
messages: + msg250289
2015-09-08 19:08:02Arfreversetnosy: + Arfrever
2015-09-04 02:27:13eric.snowsetmessages: + msg249706
2015-09-03 20:34:28eltodersetnosy: + eltoder
2015-09-03 07:28:48njssetnosy: + eric.snow
messages: + msg249612
2015-09-03 06:08:03ncoghlancreate