Use events to couple parameters in instrument drivers?

@MerlinSmiles noticed an interesting case while writing an instrument driver: sometimes different parameters are coupled to each other, such that changing one affects the value of the other(s). This means that the snapshot of this instrument will definitely be incorrect right after a set call on one of these parameters.

Sometimes this is just two different ways to call the same hardware command, eg resolution and averaging time... sometimes you want to specify one, sometimes the other, but they both generate identical hardware calls. In that case, we could probably work out a way to determine the value of the other parameter programmatically, but it would be easiest to just ask the instrument.

Other times they are separate parameters that don't have a 1:1 mapping but they impose constraints on each other. In that case, unless we want to figure out the details of these constraints and hard code them into the driver (which sounds horrible!) you need to ask the instrument for the other parameter(s).

It occurred to me the easiest way to build in such couplings would be through events. In this case we would do something like:

def update_res_and_time(self):
    self.resolution.get()
    self.integration_time.get()
    self.NPLC.get()

def __init__(self, ...):
    self.add_parameter('resolution', ...)
    self.add_parameter('integration_time', ...)
    self.add_parameter('NPLC', ...)

    self.on(('resolution_set', 'integration_time_set', 'NPLC_set'), self.update_res_and_time)

Where the parameter would know, because it's attached to this instrument, to emit a '<name>_set' event on setting (and maybe a '<name>_get' event on getting too?) on this instrument's event emitter.

But I haven't used any event systems in Python... anyone? I see pyee, gevent-eventemitter, eventemitter...

Is this the right way to do this or is there something better? Do we need such events to extend beyond the walls of the instrument (which in practice would also mean extending beyond this PROCESS, which would make it quite a bit more involved)? pyee looks nice and lightweight, people seem to like it, so that's what I would go with all else equal.