[whalesalad]

I try to treat real/physical Python objects as disposable. Everything in the runtime can be recreated from something else - be it a file on disk, a table in a DB, redis, a blob on S3, etc… and try not to put too much weight on the actual objects themselves. Modifying an object is really not something I ever do. I/O is dealt with elsewhere. I guess you could call it a hybrid approach of functional programming where objects are just used as structs that might have a few methods for synthetic properties.

For that reason I’m having a tough time seeing the use case for this. I could see it being useful with “bad” code that mutates things it shouldn’t… but can’t really think of a way I’d integrate this in an environment where I control most or all of the code.

[nightfly]

> this package tries to make immutable objects to make it easier avoid accidental modifications in your code.

Seems like it's insurance, which doesn't seem bad

[diegojromero]

Exactly my main issue. I see this code as something that asserts that an object is not modified by that "bad" code, but I fail to see more use-cases. I've been thinking about doing some kind of dictionary datastore with these frozen objects but I'm not sure if it is actually useful.