Thanks for your comment! It has given me an idea for a project: a simple library that provides a Python decorator that can be used to include basic telemetry for functions in Python code (think spans with the input parameters as attributes): https://github.com/diegojromerolopez/otelize
I knew about dataclasses when I started writting gelidum, but I wanted to make the immutable objects be from any classes, those under my control or not.
Having said that, I think dataclasses are a better solution for making immutable objects if the class is going to be made from the start.
Performance is bad, I mean, all params are deep-copied because I assume frozen then "inplace" is not intended as they could be objects used by other parts of code.
I added this feature yesterday. Note the default value is "exception". With "nothin" I was thinking in passing some frozen object through a pipeline of unsafe/inherited/bad code, but without polluting the console with warnings or stopping the execution with exceptions.
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.
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.
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.
Speaking as someone who Friday had to fix an embarrassing bug in my Python code because lists aren’t immutable when passed to another function, I like the way you think.
I will say, however, that what I want from Python isn’t actually “frozen” data structures but cloned ones (or, like some/most FP languages, structures with nested values that are only cloned when necessary).
Copy on modify would work, certainly. The term I was forgetting when I wrote that is “persistent” data structures, but I’m not sure whether it’s practical to implement persistent structures in a non-functional language like Python.
'The future of Programming' by Bret Victor (https://www.youtube.com/watch?v=8pTEmbeENF4). Seems a pun about OP title but it really is related with his/her question. Take a look and you will be amazed of how good (or revolutionary by our standards) some old technologies were.
About the cost, AFAIK it is not prohibitive.
I will continue working as I was, thanks for your opinion!