search

ezmsg-org / ezmsg

Pure-Python DAG-based high-performance SHM-backed pub-sub and multi-processing pattern
https://ezmsg.readthedocs.io/en/latest/
MIT License
9 stars 5 forks source link

Normalize on INPUT / OUTPUT or INPUT_SIGNAL / OUTPUT_SIGNAL for stream identifiers. #70

Closed cboulay closed 5 months ago

cboulay commented 7 months ago

Most, but not all, hand-coded units use INPUT_SIGNAL and OUTPUT_SIGNAL for the main stream identifiers. However, some use vanilla INPUT and OUTPUT. Furthermore, the new gen_to_input uses INPUT and OUTPUT.

It would be good if all of the units that ship with ezmsg used the same stream identifiers, and if those identifiers were also the names used for gen_to_unit. The latter is especially important because the identifiers are not available to IDE inspection at 'develop time' / 'compile time'.

It's possible for gen_to_unit to know the yield and send types so a possible solution would be to use INPUT_SIGNAL / OUTPUT_SIGNAL when the type is AxisArray and use the vanilla INPUT / OUPUT otherwise.

griffinmilsap commented 7 months ago

Good thoughts here -- There's a number of reasons why the gen_to_unit isn't necessarily a fully supported contribution and this is one of them. I forsee a future version of this functionality that just uses some shorthand decorators in the Unit class definition to wrap a generator as a coroutine that takes a stream that's been pre-defined in the class definition.

It seems like you've detected my nomenclature to use INPUT_SIGNAL when the input type is some sort of AxisArray. Some units that just have one input and one output still get INPUT/OUTPUT streams for ease of use (even if they're AxisArrays). I believe most of the sigproc library uses the SIGNAL designations, wheras most of the other util stuff just uses INPUT and OUTPUT