On Sun, Feb 4, 2018 at 11:28 PM, Glenn Linderman <v+python at g.nevcal.com> wrote:
> This is an interesting use case. I haven't got the internals knowledge to
> know just how just different mutable and immutable classes and objects are
> under the hood. But this use case makes me wonder if, even at the cost of
> some performance that "normal" immutable classes and objects might obtain,
> if it would be possible to use the various undisciplined initialization
> patterns as desired, followed by as declaration "This OBJECT is now
> immutable" which would calculate its HASH value, and prevent future
> mutations of the object?
It would be technically possible to support something like
@dataclass(freezable=True)
class Foo:
blah: int
foo = Foo()
# Initially, object is mutable, and hash(foo) raises an error
foo.blah = 1
assertRaises(hash, foo)
# This method is automatically generated for classes with freezable=True
foo.freeze()
# Now object is immutable, and hash(foo) is allowed
assertRaises(foo.__setattr__, "blah", 2)
hash(foo)
I don't know if it's worth the complexity, but I guess it would cover
at least some of the use cases Guido raised.
-n
--
Nathaniel J. Smith -- https://vorpus.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4