[issue24991] Define instance mutability explicitly on type objects?

[Nick Coghlan]

Nick Coghlan  added the comment:

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).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24991] Define instance mutability explicitly on type objects?

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee: rhettinger -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24991] Define instance mutability explicitly on type objects?

[Raymond Hettinger]

Raymond Hettinger  added the comment:

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.

--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24991] Define instance mutability explicitly on type objects?

[Nick Coghlan]

Nick Coghlan  added the comment:

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

--
components: +Interpreter Core
title: Define instance mutability explicitly on type objects -> Define instance 
mutability explicitly on type objects?
type:  -> enhancement
versions: +Python 3.8 -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24991] Define instance mutability explicitly on type objects

[Nick Coghlan]

Nick Coghlan added the comment:

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.

--
nosy: +trent

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24991] Define instance mutability explicitly on type objects

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24991] Define instance mutability explicitly on type objects

[Eugene Toder]

Changes by Eugene Toder :


--
nosy: +eltoder

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24991] Define instance mutability explicitly on type objects

[Nick Coghlan]

New submission from Nick Coghlan:

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.

--
messages: 249605
nosy: ncoghlan, njs
priority: normal
severity: normal
status: open
title: Define instance mutability explicitly on type objects
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24991] Define instance mutability explicitly on type objects

[Nathaniel Smith]

Nathaniel Smith added the comment:

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.

--
nosy: +eric.snow

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24991] Define instance mutability explicitly on type objects

[Eric Snow]

Eric Snow added the comment:

Yeah, this definitely relates to the project I'm working on.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com