Maestro IronPython Console tips and tricks

Now that I've hopefully sold you on how awesome the new IronPython Console feature of Maestro 5.0 is, here's some tips and tricks I've discovered while building and playing around with this new feature.

dir()

The dir() function lets you list members of a given variable. Very useful for see what properties and methods are available.

help()

The help() function does one better and actually dumps out the full definition of any object variable and gives you any attached API documentation as well. IronPython will auto-include any .net XML documentation of any .net type we've exposed to the IronPython scripting engine. The Maestro installation includes XML documentation for the Maestro API and Host Application, so most of the classes/methods you would be working will have documentation on hand.

However, given the small screen real estate, the help() command is somewhat impractical if the object being inspected has a lot of properties and methods. In terms of practicality, it's much easier to have the Maestro API reference help file on hand, which is included with the Maestro SDK.

.net-isms

The code you're writing is Python, but the code is running on the .net CLR so inevitably there are .net-isms that don't cleanly translate 1:1 to Python. Here's a few to take note of.

The Maestro API makes use of a lot of extension methods in its classes. However by default, these methods aren't available in the IronPython Console

To make extension methods recognisable, you have to use the ImportExtensions method from the clr module and pass in the namespace where you want the extension methods pulled in.

If you're wondering how does one know which namespace to pull the extension methods from as a general rule most, if not all extension methods in the Maestro API will be defined at the same namespace level as the classes they're extending. Note that the auto-complete functionality (or the help() function) doesn't currently pick up extension methods after they're imported, so in such cases having the Maestro API reference on hand is quite useful.

Another .net-ism to be aware of is nullable types. Most resource classes will have some nullable properties to denote XML elements which may or may not be specified. Assigning null (None in Python) to a nullable property generally won't produce the expected result.

So how do we make nullable properties actually null? Well to answer this question, lets take a step back.

As explained in a previous post, the Maestro API make heavy use of interfaces to wrap the assorted auto-generated classes into a consistent set of APIs. This was needed in order for an application to be able to access resources of various schema versions in a simple manner without having to reference the individual generated class for the specific resource schema version you want to work with.

Well, in Python there are no such thing as interfaces. What you see in the IronPython console is the full verbatim auto-generated class definition, and not the interface facade that we return to you in .net. What this means in practice is understanding how nullable properties are handled in .net XML serialization.

Simply put, each nullable property has a PropertyNameSpecified property that controls whether the property in question will be included or omitted when serializing back to XML. Such class properties are not included in their respective public interface, but since we're working with a language where there's no such thing as interfaces, you can get/set such properties directly. So to actually set a nullable property to null, you would set its respective PropertyNameSpecified property to false

Similarly, if you are setting a nullable property to a value that was initially null, you should make sure to set its respective PropertyNameSpecified property back to true.

The .net section of the IronPython documentation has a wealth of information about other .net-isms to be wary of.

Python standard library

IronPython includes the Python Standard Library, which we also bundle with Maestro, so anything from the Python Standard Library is usable in the IronPython console

However there are probably some parts of the Python standard library which may not play nice with the IronPython Console. I'm guessing anything involving threads, processes or asynchronous execution may have problems when used in the IronPython Console and are facilities you should probably avoid. So don't go too overboard in your script code.



Got any useful tips and tricks of your own to share? Comment on down below.