Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define instance mutability explicitly on type objects? #69179

Open
ncoghlan opened this issue Sep 3, 2015 · 8 comments
Open

Define instance mutability explicitly on type objects? #69179

ncoghlan opened this issue Sep 3, 2015 · 8 comments
Labels
3.8 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement

Comments

@ncoghlan
Copy link
Contributor

ncoghlan commented Sep 3, 2015

BPO 24991
Nosy @rhettinger, @ncoghlan, @tpn, @njsmith, @eltoder, @ericsnowcurrently

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2015-09-03.06:08:03.336>
labels = ['interpreter-core', 'type-feature', '3.8']
title = 'Define instance mutability explicitly on type objects?'
updated_at = <Date 2017-12-25.23:58:24.159>
user = 'https://github.com/ncoghlan'

bugs.python.org fields:

activity = <Date 2017-12-25.23:58:24.159>
actor = 'ncoghlan'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2015-09-03.06:08:03.336>
creator = 'ncoghlan'
dependencies = []
files = []
hgrepos = []
issue_num = 24991
keywords = []
message_count = 7.0
messages = ['249605', '249612', '249706', '250289', '307934', '307971', '309047']
nosy_count = 7.0
nosy_names = ['rhettinger', 'ncoghlan', 'trent', 'Arfrever', 'njs', 'eltoder', 'eric.snow']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue24991'
versions = ['Python 3.8']

@ncoghlan
Copy link
Contributor Author

ncoghlan commented Sep 3, 2015

Issue bpo-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.

@njsmith
Copy link
Contributor

njsmith commented Sep 3, 2015

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.

@ericsnowcurrently
Copy link
Member

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

@ncoghlan
Copy link
Contributor Author

ncoghlan commented Sep 9, 2015

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.

@ncoghlan
Copy link
Contributor Author

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

@ncoghlan ncoghlan added interpreter-core (Objects, Python, Grammar, and Parser dirs) 3.8 only security fixes labels Dec 10, 2017
@ncoghlan ncoghlan changed the title Define instance mutability explicitly on type objects Define instance mutability explicitly on type objects? Dec 10, 2017
@ncoghlan ncoghlan added the type-feature A feature request or enhancement label Dec 10, 2017
@rhettinger
Copy link
Contributor

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.

@rhettinger rhettinger assigned rhettinger and unassigned rhettinger Dec 10, 2017
@ncoghlan
Copy link
Contributor Author

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

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
@fofoni
Copy link

fofoni commented Aug 19, 2022

Sorry for digging up this old issue; I went down a rabbit-hole today that included lots of threads on python-dev and bpo/github, and now I ended up here, but the thing is:

Should this issue still be open, or is this a resolution?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.8 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

5 participants