-
Notifications
You must be signed in to change notification settings - Fork 38
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
add support to initialise NTEnum like NTScalar #154
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some coverage would need to be added to TestEnum
in src/p4p/test/test_nt.py
.
@@ -267,18 +267,41 @@ def testSubStore(self): | |||
self.assertEqual(V.a.value.index, 1) | |||
self.assertEqual(V.b.value.index, 0) | |||
|
|||
def testWrap(self): | |||
def testDictionaryOfValueWrap(self): | |||
W = nt.NTEnum() | |||
V = W.wrap({'index':1, 'choices':['X','Y']}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This existing test fails because it goes through the isinstance(value, dict)
branch in NTEnum.wrap(), which now expects 'value.index' and/or 'value.choices' like NTScalar.wrap() does. Should I update this test, or should NTEnum.wrap() be able to handle a dictionary that only contains fields meant for the Value.value?
When initialising an NTEnum with a python dict, it is assumed that the dict is meant for the Value.value and contains
index
andchoices
keys for the value. This PR adds ability to initialise value and any other fields of the NTEnum, similar to initialising an NTScalar.