-
Notifications
You must be signed in to change notification settings - Fork 1
Description
front, like a growing number of packages out there, depend on annotations to do their job.
Yet the python objects we'll want to dispatch are not always annotated, or not annotated as we'd like them to be (e.g. we might want the more precise Enum('Color', {'red': 'red', 'green': 'green', 'blue': 'blue'}) rather than just str).
Further, our need for annotations is our (dispatching) concern, not (necessarily) the concern of the code we're dispatching -- and we believe in SoC.
And now, the usual "rules over unruly" argument:
Annotating our objects manually is fine for a few objects, but when we dispatch multiple objects, we'd like to rely on consistent rules that get us to what we need with minimal manual intervention.
Right now, we're just going to provide a simple one to cover a few basic cases (namely injecting annotations based on argname and on type).
As things evolve (if they do), we may want to make a more powerful framework for this.
We've done this before (e.g. in py2api's little transformations language), and have a few general frameworks (or explorations thereof) in the the form of
i2.io_trans,
i2.routing_forest, and
i2.switch_case_tree.
Some i2mint and otosense code has been commented with the keyword "pattern" to indicate were we might find some example instances of this framework's need.
See also: similar issue in front