Skip to content
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

butler-specific policy class #6

Merged
merged 1 commit into from Dec 15, 2015
Merged

butler-specific policy class #6

merged 1 commit into from Dec 15, 2015

Conversation

n8pease
Copy link
Contributor

@n8pease n8pease commented Nov 13, 2015

adds a pure python butler policy class. basically nested dicts,
but implemented as a class that adds some functionality to
support policy-ish api, such as dot delimited hierarchical
access.

- yaml: read and write is supported.
- pex policy: read is supported, although this is deprecated and will at some point be removed.
"""

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's usual to have an __init__() method, even if all it does is set self.data to something sensible. You might also want to be able to create a Policy directly from a yaml or pex_policy file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could add one, but it would just call the base class init. is that desirable?
There are methods to create Policy from yaml, and pex_policy, but it's explicit. I was thinking about creating a version of init that accepts a var and then implements overloading behavior (i.e. dispatch) based on var type. does that seem desirable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re. explicit methods, now I've seen your comment below. I'll work the ctor.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so there's a polymorphic init now. I suspect the pythonistas will ding me on this as type checking tends to be discouraged in python (as opposed to duck typing) but I think in this case it's justifiable. I'm happy to discuss it though.

:param name:
:return: the value for the given name.
"""
warnings.warn_explicit("Deprecated. Use []", DeprecationWarning)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if there's a better way to mark methods as deprecated I'd like to know about it. These don't actually do anything; the DeprecationWarning is ignored by default. But it's more than nothing at least.

class Policy(UserDict.UserDict):
"""Policy implements a datatype that is used by Butler for configuration parameters.
It is essentially a dict with key/value pairs, including nested dicts (as values). In fact, it can be
initialized with a dict. The only caviat is that keys may NOT contain dots ('.'). This is explained next:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"caveat"

adds a pure python butler policy class. basically nested dicts,
but implemented as a class that adds some functionality to
support policy-ish api, such as dot delimited hierarchical
access.
@n8pease n8pease merged commit 327198b into master Dec 15, 2015
@ktlim ktlim deleted the tickets/DM-4171 branch August 25, 2018 06:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants