wasatch.SpectrometerRequest.SpectrometerRequest Class Reference

Public Member Functions
	__str__ (self)
	clear (self)

Static Public Attributes
list	args = field(default_factory=list)
str	cmd = ''
dict	kwargs = field(default_factory=dict)

Detailed Description

As far as I can tell, this was _literally_ an attempt to pass a Python 
function call across a pickled multiprocess.Queue.

foo(a, b, x=1, y=2) -> list(int)
    became 
SpectrometerRequest("foo", args=[a, b], kwargs={"x": 1, "y": 2}) -> SpectrometerResponse(data=list(int))

And SpectrometerResponse, in turn, was an attempt to return values (including
exceptions) back across a multiprocess.Queue.

I think we ended up here because we attempted to support return-values
(necessitating SpectrometerResponse) before we moved from multiprocess to 
multithreaded. 

It prompts one to wonder whether we could obviate this architecture entirely,
however...

We honestly don't WANT ENLIGHTEN calling directly into InterfaceObjects, 
because that could create all manner of multi-threaded contention on the USB
_serial_ bus. The fact that these requests can be neatly queued, dedupped and
serviced in order is a feature, not a bug.

Member Function Documentation

__str__()

wasatch.SpectrometerRequest.SpectrometerRequest.__str__

(

self

)

clear()

wasatch.SpectrometerRequest.SpectrometerRequest.clear

(

self

)

Member Data Documentation

args

list wasatch.SpectrometerRequest.SpectrometerRequest.args = field(default_factory=list)

static

cmd

str wasatch.SpectrometerRequest.SpectrometerRequest.cmd = ''

static

kwargs

dict wasatch.SpectrometerRequest.SpectrometerRequest.kwargs = field(default_factory=dict)

static

---

The documentation for this class was generated from the following file:

• wasatch/SpectrometerRequest.py