In this post, I introduced some of the changes we are making to the VTK wrappers. One of these is the introduction of an operator to easily connect sources and filters. I initially proposed using >>. Later | was suggested:
The pipe | symbol is well known especially for linux users. The direction of data flow is implicit.
The >> symbol points in the direction of data flow which is a neat bit of information to add in, especially for beginners. Also the >> is more visually apparent. So >> is my vote, unless there is some weird python syntax or pattern that gets in the way etc.
What we want is a simple syntax for describing a graph. The nodes are the filters, each node has properties. The edges are the connections, each edge has properties to specify the output port number and the input port number.
Note than when we create a filter we can set a name for the filter with SetObjectName(). So we can easily set names for the nodes in the graph.
I do have a related question. Let’s say that we implement some utility functions/classes like this and we want them to be included when one includes the vtkCommonExecutionModel module. How would one do that? Change the vtkCommonExecutionModel to something like this?
from .vtkCommonExecutionModelCompiled # this is the .so file. We need to rename it I guess?
We can provide those functions from the .so file instead of doing it in python. Just like execute is generated in vtkAlgorithmPython.cxx, the wrapper would generate new functions in C++ that return an output port for an algorithm.
I am not happy with this either. We can do (and I like):
AFilter().output_port(1) >> BFilter()
This is not feasible:
AFilter() >> BFilter(input_port=1, ...)
If the input_port is passed as a constructor argument, it would become intrinsic to the filter which affects future connections. Also, I like the idea of everything flowing left to right (meaning, the input port selection should come before the filter). So how about this: