34 ArcUser April–June 2005 www.esri.com
Scripting in ESRI software has historically followed two models. The
fi rst model is demonstrated by ARC Macro Language (AML). This
model shows its PrimOS heritage. Output is piped to fi les, data han-
dling is fi le system and directory based, and the code is very linear in
nature.
The second model is exemplifi ed by Avenue that shows its Smalltalk
origins. Object.request is the name of the game: things donʼt have to be
linear, I/O is sometimes a struggle, and integrating with other programs
is a mixed bag. Both are custom languages that have their own dark,
nasty corners.
With the introduction of ArcGIS 8, your scripting-based view of the
world was turned upside down. Interface-based programming required
you to use a “real” programming language, such as C++ or Visual Ba-
sic, to access the functionality of ArcGIS 8. There was no script for
automating a series of tasks. Instead, you had to write executables, nav-
igate a complex tree of interfaces and objects to fi nd the required tools,
and compile DLLs and type libraries to expose custom functionality.
With the introduction of ArcGIS 9, ESRI is again providing access
to its software through scripting. ESRI realized that many of its users
donʼt want or need to be programmers but would still like to have tools
to solve problems they encounter. These tools include nice, consistent
GUIs; scriptable objects; and the nuts-and-bolts programming tools
necessary for customization.
To fulfi ll this need, ESRI supports a variety of scripting languages
using ArcObjects—starting with the geoprocessing framework. Python,
one of the languages supported, is an Open Source, interpreted, dynami-
cally typed, object-oriented scripting language. Python is included with
ArcGIS 9 and is installed along with the other components of a typical
installation. This article gives you an overview of what is available in
the Python universe to help you with GIS programming and integrating
ESRI tools.
Introducing Python
Python was fi rst released in 1991 by Guido van Rossum at Centrum
voor Wiskunde en Informatica (CWI) in the Netherlands. Yes, it is
named after Monty Pythonʼs Flying Circus, which Guido loves. Its
name also means that references from the movies and television show
are sprinkled throughout examples, code, and comments. Many of
Pythonʼs features have been cherry-picked from other languages such
as ABC, Modula, LISP, and Haskel. Some of these features include
advanced things, such as metaclasses, generators, and list comprehen-
sions, but most programmers will only need Pythonʼs basic types such
as the lists, dictionaries, and strings.
Although it is almost 13 years old, Python is currently at release
2.3. This refl ects the design philosophy of the Benevolent Dictator for
Life (Guido) and the group of programmers that continue to improve
Python. They strive for incremental change and attempt to preserve
backwards compatibility, but when necessary, they redesign areas seen
in hindsight as mistakes.
By Howard Butler, Iowa State University
The Design of Python
Python is designed to be an easy-to-use, easy-to-learn dynamic script-
ing language. What this means for the user is that there is no compiling
(the language is interpreted and compiled on the fl y), it is interactive
(you can bring up the interpreter prompt much like a shell and begin
coding right away), and it allows users to learn its many layers of im-
plementation at their own pace.
The design philosophy of Python was most clearly described by Tim
Peters, one of the lead developers of Python, in “The Zen of Python.” Py-
thon programmers can use these maxims to help guide them through the
language and help them write code that could be considered pythonic.
Python and GIS
Python provides many opportunities for integration within GIS com-
puting systems. Cross-platform capabilities and ease of integration with
other languages (C, C++, FORTRAN, and Java) mean that Python is
most successful in gluing systems together. Because of the fl uid lan-
Python Universe
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules,
Although practicality beats purity.
Errors should never pass silently,
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one—and preferably only one—obvious way
to do it.
Although that way may not be obvious at fi rst unless you’re
Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a
good idea.
Namespaces are one honking great idea—let’s do more
of those!
for ESRI Users
A Guide to the
资源评论
