[Python-Dev] Another case for frozendict (original) (raw)

R. David Murray rdmurray at bitdance.com
Wed Jul 16 19:17:11 CEST 2014

On Wed, 16 Jul 2014 10:10:07 -0700, Devin Jeanpierre <jeanpierreda at gmail.com> wrote:

On Wed, Jul 16, 2014 at 6:37 AM, R. David Murray <rdmurray at bitdance.com> wrote: > IMO, preventing someone from shooting themselves in the foot by modifying > something they shouldn't modify according to the API is not a Python > use case ("consenting adults").

Then why have immutable objects at all? Why do you have to put tuples and frozensets inside sets, instead of lists and sets? Compare with Java, which really is "consenting adults" here -- you can add a mutable object to a set, just don't mutate it, or you might not be able to find it in the set again. Several people seem to act as if the Pythonic way is to not allow for any sort of immutable types at all. ISTM people are trying to retroactively claim some standard of Pythonicity that never existed. Python can and does protect you from shooting yourself in the foot by making objects immutable. Or do you have another explanation for the proliferation of immutable types, and the inability to add mutable types to sets and dicts? Using a frozendict to protect and enforce an invariant in the re module is entirely reasonable. So is creating a new dict each time. The intermediate -- reusing a mutable dict and failing in incomprehensible ways if you mutate it, and potentially even crashing due to memory safety issues -- is not Pythonic at all.

You'll note I ended up agreeing with you there: when mutation breaks an invariant of the object it came from, that's an issue. Which would be the case if you could use mutable objects as keys.

--David

More information about the Python-Dev mailing list