If a member attribute of the Device class is not serializable, attempting to access the list of Properties and Methods of the Device fails to list any members and throws an exception. Expected behaviour would be to skip (or issue a warning about) the offending member and still list the others.
To reproduce easily, just add a bad_object = set() to any existing device and try accessing it via control client, e.g.:
class VerySimpleDevice(Device):
param = 10
bad_object = set()
$ ./lewis.py -r localhost:10000 -k lewis.examples simple_device
$ ./lewis-control.py device
Traceback (most recent call last):
File "./lewis-control.py", line 24, in <module>
control_simulation()
File "lewis/scripts/control.py", line 107, in control_simulation
show_api(remote, args.object)
File "lewis/scripts/control.py", line 45, in show_api
member = getattr(obj, member_name)
File "lewis/core/control_client.py", line 215, in getter
return obj._make_request(property_name + ':get')
File "lewis/core/control_client.py", line 198, in _make_request
raise exception(exception_message)
TypeError: [u'set([]) is not JSON serializable']
The error does not occur if the member is protected (_bad_object), so that can be used as a workaround. But, ideally, I think the control client / server should be smart enough to deal with this in a more user-friendly way. Perhaps just something like:
$ ./lewis-control.py device
Type: VerySimpleDevice
Properties:
param
bad_object >>> TypeError: [u'set([]) is not JSON serializable']
Methods:
process
That way there's a good indication what works and what doesn't, and why.
This is an issue reported by @AdrianPotter.
If a member attribute of the
Device
class is not serializable, attempting to access the list of Properties and Methods of the Device fails to list any members and throws an exception. Expected behaviour would be to skip (or issue a warning about) the offending member and still list the others.To reproduce easily, just add a
bad_object = set()
to any existing device and try accessing it via control client, e.g.:The error does not occur if the member is protected (
_bad_object
), so that can be used as a workaround. But, ideally, I think the control client / server should be smart enough to deal with this in a more user-friendly way. Perhaps just something like:That way there's a good indication what works and what doesn't, and why.