arcpy - Why learn/use Python Toolboxes over Python Script Tools?

I've written a few Python Toolboxes (which are new at ArcGIS 10.1), but am yet to decide whether/when I should write them rather than Python Script Tools in a standard toolbox.

I thought the Online Help might enlighten me when it prefaces some dot points with:

Once created, tools in a Python toolbox provide many advantages

However, the five advantages listed all seem to be over not being able to use Python to write tools, and none seem to specify an advantage of Python Toolboxes over Python Script Tools.

The two advantages that I can think of are:

• I can now write a "pure" Python tool in a single Python script without having to hook it up to a separately authored dialog with its Tool Validation looking like it was tacked on but I'm happy to be pragmatic rather than pure in this regard


• I could now use code (Python or any language capable of writing text files) to automate the writing of Python toolboxes but I am yet to come across a requirement to do this

Am I overlooking the compelling case that led Esri to provide the Python Toolbox capability and, if so, what is it?

Answer

The two are very, very close in functionality but not completely equivalent.

Common to both

• Includes a set of tools with a unique alias for identification


• Can call from arcpy



• Get a Geoprocessing tool dialog (essentially a full UI) for free for each tool


• Can keep all Python code in one file (embedding tool source in TBX, holding all the implementation in one PYT) and distribute via email or shared network drives


• Always run in foreground setting for desktop applications. Setting "Always run in foreground" within ArcPy code?

Unique to TBX files:

• Can include references to system toolboxes, custom COM tools, and custom .Net tools


• Model Builder tools can be included in the toolbox


• Tool documentation is stored inside the .tbx file


• Easy wizard UI for setting up parameters and doing validation code



• Run Python Script in Process tool property


• Disadvantage: Opaque binary format, newer versions of TBX files need to be explicitly saved as older versions to work in previous versions of the software, the UI can be a double edged sword as you have to switch between property pages to see if you missed a setting (such as relative paths)

Unique to Python Toolboxes:

• Plain text, so toolboxes can be treated the same as any other code (useful in environments where good revision control tooling is used as you can trace its development history -- look at how many projects on GitHub use PYT over TBX.)


• Have more control over certain parameter types (namely you can do composite datatypes and define value tables' schemata)


• isLicensed property can be used to disable a tool if a product ("ArcInfo") or extension ("spatial") is not available.


• Tool documentation is stored in XML files in same folder as the .pyt


• Disadvantage: No wizard UI for configuring tool parameters, significantly more scaffolding code in Python, turns Toolbox development into more of a formal software development task over simply adding an implementation script. Reloading a pyt to load changes while developing can be slow if pyt is large (this can be avoided by putting tools in other files and importing so they don't need to be re-compiled).

A while ago when I was working on my first dozen or so PYT toolboxes I got flustered at how much of a hassle it was to set up a PYT for the first time, so I developed a tool called tbx2pyt. It'll take a TBX toolbox and convert it to a PYT with a minimal loss of code. In fact, the PYT that powers it was first a TBX. This may be a good way to transition existing tools to the Python Toolbox format if you so desire. At the very least, it makes it possible to set up your tools' parameters using the UI before switching to code.