Closed ptrba closed 1 year ago
Simply never thought of that case.
I think the way you have it is nearly same as I would (would just use self._box_config["frozen_box"]
instead of other.
)
Adding this feature in Box 7! Please test and give feedback if possible pip install python-box[all]~=7.0.0rc0
Added in 7.0.0
Frozen boxes are great for enforcing a functional style of programming at runtime. But the implementation of
Box.__add__
assumes that the left-hand side is non-frozen.The following piece of code fails in
box/box.py:274: box.box.Box.__add__
withbox.exceptions.BoxError: Box is frozen
As far as I can judge, there is no reason to restrict
__add__
(and__or__
) operations to non-frozen boxes. The implementation ofBox.__add__
creates a copy of the input box before merging/updating, thus the operations leave the input boxes unmodified.This implementation of
Box.__or__
would solve the issue:I've made a quick check that this works for flat and nested structures. But there might be some unintended side effects for nested structures. But this would be an issue even for non-frozen boxes. I guess most programmers will assume that writing
foobar = foo + {"bar": 1}
won't mutate foo.What are the objections against frozen boxes in
Box.__add__
(Box.__or__
)? And, how should this be implemented?