List operation bug?
chinghwayu opened this issue · comments
# conf.py
my__var = ["hello"]
var = ["1", "2"]from config import config
module_list = ["conf.py"]
cfg = config(*module_list, separator="__", interpolate=True)
cfg.var.insert(0, "0")
print(cfg.var) # result is ["1", "2"]
cfg.my.var.insert(0, "hello again")
print(cfg.my.var) # result is ["hello again", "hello"]
The intent was to have the config to return copies of each list, but I'm open to changing it. In other words, the correct behavior should be the first one you mentioned. Any thoughts on that?
The intent was to have the config to return copies of each list, but I'm open to changing it. In other words, the correct behavior should be the first one you mentioned. Any thoughts on that?
In my opinion, the behavior should be the second one since that's seems to be an intuitive operation. When a list is returned, the expectation is that any "standard" list operation should be able to be work. Does that make sense?
Funny, I did the opposite and "fixed" it by only returning copies of lists or to convert iterables to tuples.
I guess in the end the question boils down to whether a config object should be immutable or not. This will not work for dicts at all given that the key aggregation will not flow back to the initial structure.
ah, I see why you did that. Let me think about whether the config object should be immutable or not.
I think I'd prefer it if we keep the config objects sort of immutable to make it consistent with dictionaries, which are copies of the internal structure. PR #26 implements those changes.
To edit the config values, we can always do cfg.my['var'] = <new_list>, which I think is preferred since the user must explicitly make the changes. Otherwise, it's easy to make unwanted changes to the config values by keeping references to the internal lists.
What do you think?
I think I'd prefer it if we keep the config objects sort of immutable to make it consistent with dictionaries, which are copies of the internal structure. PR #26 implements those changes.
To edit the config values, we can always do
cfg.my['var'] = <new_list>, which I think is preferred since the user must explicitly make the changes. Otherwise, it's easy to make unwanted changes to the config values by keeping references to the internal lists.
What do you think?
I agree that the config objects should be kept immutable.
An alternative would be to allow users to flatten to a dot notation enabled dictionary such as .as_dict(dot_notation=True). This would allow end users to do such things as
cfg = config(*module_list, separator="__", interpolate=True).as_dict(dot_notation=True)
cfg.var.insert(0, "0")
There are implementations such as the one in Fabric at https://github.com/fabric/fabric/blob/1.13.1/fabric/utils.py#L186
To make sure I understand, the as_dict(dot_notation=True) would return an AttributeDict? Is there a downside of returning something like that for all .as_dict calls?
To make sure I understand, the as_dict(dot_notation=True) would return an
AttributeDict? Is there a downside of returning something like that for all.as_dictcalls?
Yes, it would return AttributeDict. I suppose there may be certain people who don't want results as dot notation and only as true dict? Perhaps default to True?
Yeah, I'll do this. I should have a version of this tonight or tomorrow.
Yeah, I'll do this. I should have a version of this tonight or tomorrow.
I just thought of another alternative which would be to add an .as_attributedict() method.
Take a look at the PR I had for this issue. Commit d22c76d should do what you want.
That was pretty quick! I tested a variety of list and dictionary methods and they all seem to work as expected.
Closed by #26.