Recipes/Primitives system about framework HOT 2 CLOSED

The general architecture of Keck-DR is based on the idea of splitting the code into discreet units with well specified interfaces.
The processing steps that are required for each image type are listed in a "recipe". Each step in a recipe is a call to a "primitive", a relatively small piece of code that performs a single operation on the input data.
Recipes don't contain logic, and are built as functions. Recipes contain the algorithms and are built as classes.
The framework provides a way to associate recipes with specific image types, and an execution engine that runs that recipe.

A key element of this design is that it enables code sharing and reuse.
In this design, recipes are, in general, specific to an instrument. Primitives, instead, can be either specific to an instrument or more general. For example, a primitive that subtract the overscan is generic and can be used on any instrument where an overscan region is present, but the need to subtract an overscan or not is specific to an instrument, so that the recipe for that instrument will or will not include this primitive as needed.

Because of this design, primitives must be arrange in a hierarchy that defines the generalization and inheritance. Python (and other Object Oriented languages) provide a natural way of doing this by means of subclassing.

We envision the creation of a base primitive class, and then the creation of additional primitive classes that are increasingly specific in terms of area of operation or instrument, each of which would subclass the higher level, more generic classes as needed.

An an example:

BasePrimitiveClass

The base CCD methods such as read, write, subtract a bias are implemented as a CCDPrimitives class which subclasses the BasePrimitive Class. Other generic classes might have to do with logging, or display.
The specific instrument primitive class, such as KCWIPrimitives, will subclass all the classes it needs, plus provide the additional methods that are specific to the instrument.
At the end, only one instrument-specific class will be instantiated and passed as an argument to the primitive, which calls a sequence of methods to perform a complex set of operations.

This is an example of this implementation for a primitive.

class KCWIPrimitives(CCDPrimitives, IOPrimitives):
   def __init__(self):
       super(KCWIPrimitives).__init__()
   def my_method_1(self):
       do_something()
   def my_method_2(self):
       do_something_else()

And for a recipe:

from KCWIPrimitives import KCWIPrimitives
def process_this_frame(p, frame):
   p.my_method_1()
   p.my_method_2()

The engine would first instantiate the class, then trigger the recipe:

 p = KCWIPrimitives()
 process_this_frame(p, frame)

from framework.

If recipes are classes as well, they are easier to customize. For consideration.

from framework.