A major feature of INTViewer 5.2 is the Python integration. Our development team worked very hard to ensure that our customers can get started easily and be productive once they are hooked.
One consistent user feedback was that the Python terminal lacked autocompletion. It could become tedious to have to type the full name of each class, each method or each variable. We took this feedback to heart and implemented autocompletion in INTViewer 5.2.
Just like any other editor, to trigger autocompletion, just type a partial name then press Ctrl+Space on your keyboard. If there is only one match possible, the Python terminal will autocomplete your line.
For example, if a seismic layer has the variable name “layer”, typing layer.setPl will autocomplete to layer.setPlotType(.
Another refinement is that the signature of the setPlotType method is displayed at the bottom of the screen. Also, the parameter that this method expects is displayed as a shadow in the same line.
If several matches are possible, a contextual menu is shown.
All of these features are expected in a Python editor. But to deliver on the promise that the INTViewer Python API was easy to learn, we wanted to go beyond. The first work order was to add the concept of enumeration. If a method only accepts a defined set of parameter values, these values should be hinted at. Upon pressing Ctrl+Space on your keyboard, the Python terminal will show all these possible values.
In this contextual menu, the menu items with a purple dot show enumerated values. The green dots are for variables already defined and the yellow dots are for class constructors.
If you plug your own Python classes, we made it incredibly easy to enable completion for enumerated values, just by adding a StaticStringEnumParam annotation. Here is an example for the setPlotType method:
In the Java language, enumerations are static: The set of values is defined as part of the enumeration definition and cannot be changed.
INTViewer is a highly pluggable application and enumerated sets are often only known at runtime. For example, many customers plug their own trace processors. It’s only when INTViewer starts that each installed plugin is inspected for trace processors. As a result, we also implemented dynamic enumerations.
The SeismicLayerProcessor class is the perfect example of dynamic enumerations. To find the list of possible trace processor names, INTViewer looks up which trace processors are currently plugged.
The definition of such dynamic enumerations is also quite simple. With the DynamicStringEnumParam annotation, INTViewer searches for the specified method in the specified class to generate the list of proposed options.
This is the first example of a “live” autocompletion. This is a feature that commercial Python editors typically do not provide because they lack the deep integration with the runtime environment.
If we only provided dynamic enumerations, calling our autocompletion “Live Completion” would be a bit of a stretch. The ground-breaking feature is that this live autocompletion doesn’t just apply to classes, it also applies to instances of these classes.
For example, in the screenshot below, the dataset manipulated has only 2 keys: TraceNumber and Time. When I type data.getMinimum(, the two proposed values are TraceNumber and Time.
For another dataset that has 3 keys, I will get a different set of key names:
As enumerated values are generated dynamically based upon the instance, not the class, we are able to provide a much more powerful autocompletion than a typical Python editor can provide. A python editor doesn’t execute your code, it can only perform a static analysis. The Python terminal has a different behavior where each line entered is executed on the fly, allowing us to inspect the set of local variables already defined and make more much insightful suggestions.
Defining your own dynamic instance-based enumeration is simple. In the example below using the InstanceStringEnumParam annotation, getKeyNames is a method defined in the same class as the getKeyMinimum method.
Dynamic enumerations really provide extra help for users to learn the INTViewer API. It’s a powerful mechanism that we also leverage when users instantiate datasets. Each resource in INTViewer has a path, typically a file path. Remembering and typing that exact file path is a cumbersome task, so we made the entry of paths “live” as well.
INTViewer recognizes the methods that require paths as parameters, and autocompletes these parameters, filtering out files that are not of the specified type. You are not limited to browsing your local file system—this autocompletion also works for remote data servers such as INTGeoServer:
As a developer, you can easily leverage this mechanism with the DataPathParam annotation. Here is the definition of the SeismicData constructor:
For files that are not data files, a simple PathParam annotation is available:
We put a great deal of effort into INTViewer Python capabilities and are really proud of what we were able to accomplish. To get started with Python in INTViewer, visit our help guide!
For more information about INTViewer, check out our other blogs, visit the INTViewer product page, or contact us for a free trial.
