Show HN: Gelidum – My Python library to freeze objects • Hacker News Board

Re: Show HN: Gelidum – My Python library to freeze objects

#21

Post by diegojromero » Tue, Jun 15, 2021, 8:14 AM UTC

whalesalad wrote: post #10

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 ob…

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.

Re: Show HN: Gelidum – My Python library to freeze objects

#22

Post by diegojromero » Tue, Jun 15, 2021, 8:19 AM UTC

emef wrote: post #4

# 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.

Yes, you're right with your concerns.

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.

Re: Show HN: Gelidum – My Python library to freeze objects

#23

Post by diegojromero » Tue, Jun 15, 2021, 8:21 AM UTC

nickysielicki wrote: post #15

I like the purity that might come with decorating basically everything in a codebase with `@freeze_params()`, although I wonder/worry about what the runtime overhead might be. I really wish that something like that could be checked statically.

I'd really love if that could checked statically.

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.

Re: Show HN: Gelidum – My Python library to freeze objects

#24

Post by nickysielicki » Tue, Jun 15, 2021, 8:58 AM UTC

diegojromero wrote: post #23

nickysielicki wrote: post #15

I like the purity that might come with decorating basically everything in a codebase with `@freeze_params()`, although I wonder/worry about what the runtime overhead might be. I really wish that something like that could be checked statically.

I'd really love if that could checked statically. 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 started googling around and I found the following: https://www.python.org/dev/peps/pep-0591/

It looks like mypy can actually understand the hint: https://mypy.readthedocs.io/en/stable/final_attrs.html

It sucks that this would require such a substantial effort throughout a codebase, though. I guess that’s just the inherent cost of typed python.

Re: Show HN: Gelidum – My Python library to freeze objects

#25

Post by m_mueller » Tue, Jun 15, 2021, 9:04 AM UTC

FYI there is also

    @dataclass(frozen=True)

this tends to be enough for my usecases. you can still circumvent (and sometimes have to in dataclass post_init) with object.__setattr__.

Re: Show HN: Gelidum – My Python library to freeze objects

#26

Post by diegojromero » Tue, Jun 15, 2021, 9:12 AM UTC

m_mueller wrote: post #25

FYI there is also @dataclass(frozen=True) this tends to be enough for my usecases. you can still circumvent (and sometimes have to in dataclass post_init) with object.__setattr__.

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.

Re: Show HN: Gelidum – My Python library to freeze objects

#27

Post by diegojromero » Tue, Jun 15, 2021, 10:00 AM UTC

nickysielicki wrote: post #24

diegojromero wrote: post #23

Earlier quoted context omitted.

I'd really love if that could checked statically. 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 started googling around and I found the following: https://www.python.org/dev/peps/pep-0591/ It looks like mypy can actually understand the hint: https://mypy.readthedocs.io/en/stable/final_attrs.html It sucks that this would require such a substantial effort throughout a codebase, though. I guess that’s just the inherent cost of typed python.

Interesting, maybe adding a decorator @freeze_final could be a good idea? I'll take a look at it later.

Thank you for your input!

Re: Show HN: Gelidum – My Python library to freeze objects

#28

Post by macintux » Tue, Jun 15, 2021, 10:12 PM UTC

diegojromero wrote: post #20

macintux wrote: post #3

Earlier quoted context omitted.

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). Vals, not vars.

Interesting idea, instead of a deep clone, would it be something similar to the copy-on-modify pattern?

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.

https://hypirion.com/musings/understanding-persistent-vector...

Re: Show HN: Gelidum – My Python library to freeze objects

#29

Post by macintux » Tue, Jun 15, 2021, 10:13 PM UTC

BerislavLopac wrote: post #19

macintux wrote: post #3

Earlier quoted context omitted.

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). Vals, not vars.

> lists aren’t immutable when passed to another function Well, lists are never immutable in Python; you want to use tuples for that.

True, what I really want is referential transparency, not immutability per se.

I’ve only used tuples in Python as a small data structure, will have to experiment with using them as a list substitute, thanks.

Re: Show HN: Gelidum – My Python library to freeze objects

#30

Post by BerislavLopac » Wed, Jun 16, 2021, 11:52 AM UTC

macintux wrote: post #29

BerislavLopac wrote: post #19

Earlier quoted context omitted.

> lists aren’t immutable when passed to another function Well, lists are never immutable in Python; you want to use tuples for that.

True, what I really want is referential transparency, not immutability per se. I’ve only used tuples in Python as a small data structure, will have to experiment with using them as a list substitute, thanks.

Just keep in mind that a tuple's elements can still be mutable, so it's not a "frozen" data structure throughout.