API extensions

[papr]

Potentially growing list of API extension:

• get_device_option_range_ex: Mirrors lrs, returns DeviceOptionRange
• get_device_options: Mirrors lrs, returns list of doubles
• get_available_options: Uses get_device_option_range_ex to find all available options and queries their current value efficiently using get_device_options

[toinsson]

nice additions, don't forget to add some docstrings for the documentation (I wrote them for these commits)

2 comments:

• is there a reason why get_available_options does not return a generator?
• StreamMode and DeviceOptionRange might be better off into stream.py - which could require a file name change too.

[papr]

1. I guess you meant get_device_options?
2. StreamMode and DeviceOptionRange are device specific not stream specific. *Stream are currently nice wrapper around streams. Maybe we shoudl add the possibility to initilize them with a StreamMode. But they should not have any controlling logic in them. They are just model classes.

Edit: And yes, I will work on the documentation :)

[toinsson]

1. I meant get_available_options, but I guess my question comes since I still did not fully understand why you chose to yield results in get_devices, get_device_modes - and thus why get_device_options, get_available_options are not generators themselves. Is that due to the way you intend to use them in your application?

2. StreamMode, DeviceOptionRange and *Stream are model of objects that do not exists in RS API (by opposition to constants.py and extlib.py), and created here for convenience purpose. Agreed, they should not logic in them, but I still think they belong to the same type of structure. It's a matter of cleaning core.py and refactoring but it is up for discussion.

[papr]

1. get_devices and get_device_modes enumerate their content using a for loop and calling lrs multiple times. There is a yield after each for-loop-iteration. get_available_options and get_device_options call the lrs api once to fetch all option values efficiently at once. get_device_options should return an iter() (currently a list()) of the ctypes values double array and get_available_options returns a zip generator which is equivalent to yielding the values one by one.

2. I understand and agree that the namedtuple definitions sould be moved.

[toinsson]

1. Ok, got it. I am fine with get_device_options returning a list though (only 1 call to lrs). And yielding whenever there is more than 1 call to lrs. I was testing with python2, and zip does not return a generator ... We might need to use six.zip for consistency.

2. ok, can move these to a new file. Not sure about the name: syntactic.py, sugarclasses.py, lrswrapper.py?

[papr]

1. In Python 2 zip returns a list. Since it is an iterable, the zip call should be compatible anyway.
2. Why not move them to utils.py? RealsenseError lives there already.

[toinsson]

1. yes indeed, zip exists in both but making the behaviour version agnostic is good practise though. Will include six in the dependencies if that's ok with you.

2. good call.

[papr]

I ususally prioritize short dependency lists. But I agree since six is built-in in Python 3.

[toinsson]

I'll merge everything to master, if any small change you can push to master. After that, I'll make a new distribution for pypi under 2.1.

[papr]

I still have some changes coming: Setting multiple options at once + reset to defaults. I will make a PR shortly.