Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #59172 > unrolled thread

Re: 'isimmutable' and 'ImmutableNester'

Started byFrank-Rene Schäfer <fschaef@gmail.com>
First post2013-11-12 10:39 +0100
Last post2013-11-12 10:39 +0100
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: 'isimmutable' and 'ImmutableNester' Frank-Rene Schäfer <fschaef@gmail.com> - 2013-11-12 10:39 +0100

#59172 — Re: 'isimmutable' and 'ImmutableNester'

FromFrank-Rene Schäfer <fschaef@gmail.com>
Date2013-11-12 10:39 +0100
SubjectRe: 'isimmutable' and 'ImmutableNester'
Message-ID<mailman.2445.1384249197.18130.python-list@python.org>
> All you've done is proven that you can subvert things. By fiddling
> with __hash__, __eq__, and so on, you can make sets and dicts behave
> very oddly. Means nothing.

To the contrary, it means everything about what 'isimmutable' could
contribute: security against advert or inadvert insertion of mutable objects.


2013/11/11  <random832@fastmail.us>:
>> A built-in function 'isimmutable()' shall tell efficiently whether the
>> object
>> of concern is mutable or not.
>
> What's the benefit over attempting to hash() the object?
>
> copy.deepcopy already has special case for int, string, and tuples
> (including tuples that do and do not have mutable members) - could what
> you need be accomplished by overriding __copy__ and __deepcopy__ in your
> custom class to return itself if it is immutable?

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web