Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Gelidum – My Python library to freeze objects

github.com

Post reply on HN
Print view View original

11–20 of 31 posts

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

#11

Post by 1ris »

trinovantes wrote: post #5

I wish more languages have the concept of "object/memory freezing" especially at runtime, similar to runtime assertion checks, but without using 3rd party compiler plugins to instrument my code. C++'s insane "const * const" syntax makes it hard to conceptualize when I just want "create object, do bunch of non trivial stuff, freeze object forever"

Why would you want a runtime check if you can have a compile time check?

what is insane about const * const? (although a const unique_ptr is obiously better and propagate_const ist nice) For you usecase if "create object, do bunch of non trivial stuff, freeze object forever" you propably want a IIFE.

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

#12

Post by nightfly »

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…

> 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

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

#13

Post by trinovantes »

1ris wrote: post #11
trinovantes wrote: post #5

I wish more languages have the concept of "object/memory freezing" especially at runtime, similar to runtime assertion checks, but without using 3rd party compiler plugins to instrument my code. C++'s insane "const * const" syntax makes it hard to conceptualize when I just want "create object, do bunch of non trivial stuff, freeze object forever"

Why would you want a runtime check if you can have a compile time check? what is insane about const * const? (although a const unique_ptr is obiously better and propagate_const ist nice) For you usecase if "create object, do bunch of non trivial stuff, freeze object forever" you propably want a IIFE.

Most of the time, factories or IIFE would be sufficient. Sometimes the non trivial stuff is non deterministic, requires other sources of input, or gives up cpu control that makes them insufficient for all use cases.

Also, my problem with const pointers is that they don't enforce deep immutability and can cause all sorts of compilation errors if I try to pass them to non-const functions (usually to external libraries). Then I'd end up type casting my pointers which defeats the purpose of static type checking.

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

#14

Post by rcthompson »

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.

I'm guessing this would be most useful when interfacing with naughty code that you can't rewrite. E.g. you need to call a function from another library that does something useful and also modifies its argument, and you only want it to do the useful thing.

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

#16

Post by eklitzke »

trinovantes wrote: post #13
1ris wrote: post #11

Earlier quoted context omitted.

Why would you want a runtime check if you can have a compile time check? what is insane about const * const? (although a const unique_ptr is obiously better and propagate_const ist nice) For you usecase if "create object, do bunch of non trivial stuff, freeze object forever" you propably want a IIFE.

Most of the time, factories or IIFE would be sufficient. Sometimes the non trivial stuff is non deterministic, requires other sources of input, or gives up cpu control that makes them insufficient for all use cases. Also, my problem with const pointers is that they don't enforce deep immutability and can cause all sorts of compilation errors if I try to pass them to non-const functions (usually to external libraries)…

What does it mean that they don't enforce deep immutability? If you have a const pointer or reference you can't call non-const methods or make changes to variables declared without the "mutable" modifier. As you already alluded, if you want to call some non-const methods and then make the object immutable forever you can use an IIFE:

  const auto foo = [&]() {
      Foo x;
      x.call_some_non_const_method();
      x.something_else_non_const();
      return x;
  }();
I don't know what to say about your problems with external libraries taking non-const parameters. Const correctness is one of the most basic things you learn about when you first learn C++, so whether or not you think it's a good system I can't imagine there are going to be many good external libraries that aren't const correct.

I'd also add even if you thought you could enforce this at runtime, in practice it wouldn't really work due to pointer aliasing.

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

#17

Post by rcthompson »

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.

It probably could be checked statically if someone taught the type checker about this package so that it could track which variables are frozen at which points in the code.

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

#18

Post by trinovantes »

eklitzke wrote: post #16
trinovantes wrote: post #13

Earlier quoted context omitted.

Most of the time, factories or IIFE would be sufficient. Sometimes the non trivial stuff is non deterministic, requires other sources of input, or gives up cpu control that makes them insufficient for all use cases. Also, my problem with const pointers is that they don't enforce deep immutability and can cause all sorts of compilation errors if I try to pass them to non-const functions (usually to external libraries)…

What does it mean that they don't enforce deep immutability? If you have a const pointer or reference you can't call non-const methods or make changes to variables declared without the "mutable" modifier. As you already alluded, if you want to call some non-const methods and then make the object immutable forever you can use an IIFE: const auto foo = [&]() { Foo x; x.call_some_non_const_method(); x.something_else_non…

By deep immutability, I meant Foo{Bar*} where Bar has further nested structs. It's tedious to have to manually mark every field in the tree as const to achieve deep immutability, which can easily be stripped off with a cast.

What if some of those structs are from libraries and I can't mark their inner fields as const? Yes, most libraries I've used are well tested so I don't need to worry about them modifying my fields but there's no guarantee that I won't.

> I'd also add even if you thought you could enforce this at runtime

I'm well aware this is a hard problem. It was something I frequently discussed with my lab mate who wrote his thesis on this exact topic. I'm simply saying it would be a nice-to-have construct like assertions.

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

#19

Post by BerislavLopac »

macintux wrote: post #3
diegojromero wrote: post #2

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…

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.

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

#20

Post by diegojromero »

macintux wrote: post #3
diegojromero wrote: post #2

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…

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?
Post reply on HN