-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
recursive value expansion in PathExAttMap #74
Comments
Sorry, meant to hit "cancel," not "close" |
That's a good idea, it's just that it would break the nested attribute access since |
OK @stolarczyk I opened #75 to try to address this. It looks like it behaves on the test case you provided (though I had to |
I believe it may have been intentional that the If we change this behavior, will there be another way to get the non-expanded values? I don't remember the use case and maybe I'm wrong about the original intention, but I have a vague memory of this. |
Yes, there is a way to get the original values. You just omit the 'expand=True' in the method calls. |
Is it intentional that the value expansion is performed only on the top level in
attmap.PathExAttMap.__getitem__
method?This makes the result of the literal value retrieval (lines 3 and 5) different from the same value retrieval (lines 4 and 6) in all the methods that rely on
__getitem__
, likeitems
,to_dict
etc.The illustration uses a pipestat configuration file with environment variables read by
yacman.YacAttMap
, which inherits fromattmap.PathExAttMap
:A possible solution to this would be to change the current
_safely_expand
function fromto
I'm wondering if this would cause some serious downstream issues as most of our Python packages import this one.
The text was updated successfully, but these errors were encountered: