Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
The help section titled Comparing custom and Python toolboxes has a pretty good comparison of why you might choose one over the other, although I'd be curious to hear "real world" advantages/disadvantages from those experienced in creating Python Toolboxes. – RyanDalton Jun 6 '13 at 4:32
Thanks @RyanDalton - shows how much I read the Help - I forgot about that page when writing this Question - please transfer your Comment to an Answer which I'll hold off on Accept-ing until others have had a chance to try and suggest any more compelling ones. – PolyGeo Jun 6 '13 at 4:39
I didn't see it, but I think your answer here trumps any answer in the other question. – ianbroad Apr 2 '14 at 16:25
up vote 26 down vote accepted

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.

share|improve this answer
Not going to get any better than this, thanks! Oh and I'll definitely be checking out the tbx2pyt, sounds great. – ianbroad Apr 2 '14 at 16:11
Great comparison. Just to be thorough here is the a write-up by ESRI comparing the two – JamesSLC Apr 2 '14 at 16:36
Included in the list of .tbx only is the ability to use Model Builder. – matt wilkie Apr 9 '14 at 8:51

The help section titled Comparing custom and Python toolboxes has a pretty good comparison of why you might choose one over the other, although I'd be curious to hear "real world" advantages/disadvantages from those experienced in creating Python Toolboxes.

One clear disadvantage that I read is the inability to mix/match models & scripts in a Python Toolbox, as you can in a standard Custom Toolbox.

share|improve this answer
This. Two other things of note: with a .PYT your tools' parameters and names and such are defined in code, in plain text, which is quite useful if you're a software developer working with others because the tools can be totally managed in a revision control system in a manageable way instead of being in an opaque binary format. You also have a little more control over your parameters -- for example, you can define value tables and composite datatypes in a .PYT. – Jason Scheirer Jun 6 '13 at 5:25
@JasonScheirer, can you add your comment as another answer? I think it would be more helpful there so it doesn't get buried (like most other comments). Thanks! – RyanDalton Jun 6 '13 at 5:27
I'd be interested to hear what control system you use to manage PYTs. – DPierce Jun 6 '13 at 14:59

My number one reason for leaning towards python toolboxes is for version control and source code management (see Applying version control to ArcGIS Models), followed very closely by being able to use a code editor/IDE with tab completion, regular expressions, snippet libraries, etc.

However as Ryan Dalton notes, by doing so you lose the ability to use Model Builder and old style Tools -- unless you're willing to go through the effort of building the model as per usual and then exporting to python and then rewriting to fit into the .pyt. (If you do this take a look at Guidelines for organizing Python Toolboxes (.pyt) in ArcGIS). At present this disadvantage is big enough that I've yet embark on using python toolboxes seriously.

If you have existing toolboxes you'd like to convert to .pyt, you may find Jason Scheirer's tbxtopyt partial converter useful.

As for the "compelling case?" part of the question: if you already have some software development chops, yes definitely. If like me you're 3 parts GIS Tech/Analyst and 1 part or less pythonista, not so much. (At least not yet -- I really hope this binary one or the other nature of the two approach changes in a near future release.)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.