Show HN: Gelidum – My Python library to freeze objects

Per advice from Daniel from HN (thank you!), I have reposted this Ask HN I made earlier about immutability. [1]

I was thinking the other day about my days working with Ruby On Rails and how the strings are mutable in Ruby and the freeze method. My mind wandered about that, the several freeze packages that exist (even the frozendict [2] package) that make frozen classes of objects.

I haven't worked professionally with Haskell or Erlang, but some of their functional capabilities are nice and have ejerced a big influence in my work with Ruby on Rails and Python. Specially the ideas of having immutable objects and keeping updates at minimum.

I thought on doing a freeze package that could make frozen objects recursively in Python. The idea is to make easier to share objects between threads without having to worry about updates inside threads.

However, I'm not sure that this package is useful at all. Maybe is because Python is not a well-suited language for this? Maybe is because my lack of knowledge about functional programming? Maybe is because it doesn't make sense to "freeze" objects?

Some ideas I have in the back of my mind for this package are:

- Some kind of basic datastore-server where data is immutable (threaded server?). - Storing all updates some kind of super-object by storing all history as immutable objects.

What are some sources to learn about immutability on programing languages? How could you use a freeze package in Python or other languages? Would it be useful to share information between threads?

Any advice/idea/feeback/criticism or comment on this matter is appreciated.

[1] https://news.ycombinator.com/item?id=27503947

[2] https://pypi.org/project/frozendict/

  # on_update="nothing": does nothing when an update is tried 
  frozen_shared_state = freeze(shared_state, on_update="nothing")
  frozen_shared_state.count = 4  # Does nothing, as this update did not exist

yikes. Thoughts on when this feature would ever be useful? Just the thought of working in a codebase with this subtle inconsistency makes me cringe.

I use attrs for this. The objects are not truly immutable in the sense that you can modify then if you are really determined to but typical assignment of a new value to a attrs defined field (where frozen=True) will raise an error.

https://www.attrs.org/en/stable/examples.html#immutability

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.