Programming Python (11 page)
Naturally, there are
plenty of improvements we could make here, too:
The HTML code of the initial input page in
Example 1-33
, for instance, is
somewhat redundant with the script in
Example 1-34
, and it could be
automatically generated by another script that shares common
information.In fact, we might avoid hardcoding HTML in our script
completely if we use one of the HTML generator tools we’ll meet
later, including HTMLgen (a system for creating HTML from document
object trees) and PSP (Python Server Pages, a server-side HTML
templating system for Python similar to PHP and ASP).For ease of maintenance, it might also be better to split
the CGI script’s HTML code off to a separate file in order to
better divide display from logic (different parties with possibly
different skill sets could work on the different files).Moreover, if this website might be accessed by many people
simultaneously, we would have to add file locking or move to a
database
such as ZODB or MySQL to support
concurrent updates. ZODB and other full-blown database systems
would also provide transaction rollbacks in the event of failures.
For basic file locking, theos.opencall and its flags provide the
tools we need.ORMs
(object relational mappers) for
Python such as SQLObject and SQLAlchemy mentioned earlier might
also allow us to gain concurrent update support of an underlying
relational database system, but retain our Python class view of
the data.In the end, if our site grows much beyond a few interactive
pages, we might also migrate from basic CGI scripting to a more
complete
web framework
such as one of those
mentioned at the start of this section— Django, TurboGears,
pyjamas, and others. If we must retain information across pages,
tools such as cookies, hidden inputs, mod_python session data, and
FastCGI may help too.If our site eventually includes content produced by its own
users, we might transition to Plone, a popular open source Python-
and Zope-based site builder that, using a workflow model,
delegates control of site content to its producers.And if
wireless
or
cloud
interfaces are on our agenda, we might
eventually migrate our system to cell phones using a Python port
such as those available for scripting Nokia platforms and Google’s
Android, or to a cloud-computing platform such as Google’s
Python-friendly App Engine. Python tends to go wherever technology
trends lead.
For now, though, both the GUI and web-based interfaces we’ve
coded get the
job done.
And that concludes our sneak preview demo of Python in action. We’ve
explored data representation, OOP, object persistence, GUIs, and website
basics. We haven’t studied any of these topics in any great depth.
Hopefully, though, this chapter has piqued your curiosity about Python
applications programming.
In the rest of this book, we’ll delve into these and other
application programming tools and topics, in order to help you put Python
to work in your own programs. In the next chapter, we begin our tour with
the systems programming and administration tools available to Python
programmers.
The Python “Secret Handshake”
I’ve been involved with Python for some 18 years now as of this
writing in 2010, and I have seen it grow from an obscure language into
one that is used in some fashion in almost every development
organization and a solid member of the top four or five most widely-used
programming languages in the world. It has been a fun ride.
But looking back over the years, it seems to me that if Python
truly has a single legacy, it is simply that Python has made quality a
more central focus in the development world. It was almost inevitable. A
language that requires its users to line up code for readability can’t
help but make people raise questions about good software practice in
general.
Probably nothing summarizes this aspect of Python life better than
the standard librarythismodule—a sort of
Easter egg in Python written by Python core developer
Tim Peters, which captures much of the design philosophy
behind the language. To seethisfor
yourself, go to any Python interactive prompt and import the module
(
naturally
, it’s available on all
platforms):
>>>import thisThe 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 first 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!
>>>
Worth special mention, the “Explicit is better than implicit” rule
has become known as “EIBTI
” in the Python world—one of Python’s defining ideas, and
one of its sharpest contrasts with other languages. As anyone who has
worked in this field for more than a few years can attest, magic and
engineering do not mix. Python has not always followed all of these
guidelines, of course, but it comes very close. And if Python’s main
contribution to the software world is getting people to think about such
things, it seems like a win. Besides, it looked great on the
T-shirt.
This first in-depth part of the book presents Python’s system
programming tools—interfaces to services in the underlying operating
system as well as the context of an executing program. It consists of the
following chapters:
- Chapter 2
This chapter provides a comprehensive first look at commonly
used system interface tools. It starts slowly and is meant in part
as a reference for tools and techniques we’ll be using later in the
book.- Chapter 3
This chapter continues the tour begun in
Chapter 2
, by showing how Python’s system interfaces
are applied to process standard streams, command-line arguments,
shell variables, and more.- Chapter 4
This chapter continues our survey of system interfaces by
focusing on tools and techniques used to process files and
directories in Python. We’ll learn about binary files, tree walkers,
and so on.- Chapter 5
This chapter is an introduction to Python’s library support
for running programs in parallel. Here, you’ll find coverage of
threads, process forks, pipes, sockets, signals, queues, and the
like.- Chapter 6
This last chapter is a collection of typical system
programming examples that draw upon the material of the prior four
chapters. Python scripts here perform real tasks; among other
things, they split and join files, compare and copy directory trees,
test other programs, and search and launch files.
Although this part of the book emphasizes systems programming tasks,
the tools
introduced
are
general-purpose and are used often in later chapters.
This chapter begins our in-depth look at ways to apply Python to
real programming tasks. In this and the following chapters, you’ll see how
to use Python to write system tools, GUIs, database applications, Internet
scripts, websites, and more. Along the way, we’ll also study larger Python
programming concepts in action: code reuse, maintainability,
object-oriented programming (OOP), and so on.
In this first part of the book, we begin our Python programming tour
by exploring the
systems application domain
—scripts
that deal with files, programs, and the general environment surrounding a
program. Although the examples in this domain focus on particular kinds of
tasks, the techniques they employ will prove to be useful in later parts
of the book as well. In other words, you should begin your journey here,
unless you are already a Python systems programming wizard.
Python’s system interfaces span application domains, but for the
next five chapters, most of our examples fall into the category
of
system tools
—programs sometimes
called command-line utilities, shell scripts, system administration,
systems programming, and other permutations of such words. Regardless of
their title, you are probably already familiar with this sort of script;
these scripts accomplish such tasks as processing files in a directory,
launching test programs, and so on. Such programs historically have been
written in nonportable and syntactically obscure shell languages such as
DOS batch files, csh, and awk.
Even in this relatively simple domain, though, some of Python’s
better attributes shine brightly. For instance, Python’s ease of use and
extensive built-in library make it simple (and even fun) to use advanced
system tools such as threads, signals, forks, sockets, and their kin;
such tools are much less accessible under the obscure syntax of shell
languages and the slow development cycles of compiled languages.
Python’s support for concepts like code clarity and OOP also help us
write shell tools that can be read, maintained, and reused. When using
Python, there is no need to start every new script from scratch.
Moreover, we’ll find that Python not only includes all the
interfaces we need in order to write system tools, but it also fosters
script
portability
. By employing Python’s standard
library, most system scripts written in Python are automatically
portable to all major platforms. For instance, you can usually run in
Linux a Python directory-processing script written in Windows without
changing its source code at all—simply copy over the source code. Though
writing scripts that achieve such portability utopia requires some extra
effort and practice, if used well, Python could be the only system
scripting tool you need to use.
To make this part of the book easier to study, I have broken it
down into five chapters:
In this chapter, I’ll introduce the main system-related
modules in overview fashion. We’ll meet some of the most commonly
used system tools here for the first time.In
Chapter 3
, we continue
exploring the basic system interfaces by studying their role in core
system programming concepts: streams, command-line arguments,
environment variables, and so on.Chapter 4
focuses on the
tools Python provides for processing files, directories, and
directory trees.In
Chapter 5
, we’ll move on to
cover Python’s standard tools for parallel
processing—
processes, threads, queues,
pipes, signals, and more.Chapter 6
wraps up by
presenting a collection of complete system-oriented programs. The
examples here are larger and more realistic, and they use the tools
introduced in the prior four chapters to perform real, practical
tasks. This collection includes both general system scripts, as well
as scripts for processing directories of files.
Especially in the examples chapter at the end of this part, we
will be concerned as much with system interfaces as with general Python
development concepts. We’ll see non-object-oriented and object-oriented
versions of some examples along the way, for instance, to help
illustrate the benefits of thinking in more strategic ways.
“Batteries Included”
This chapter, and those that follow, deal with both the Python
language and its
standard library
—a collection of
precoded modules written in Python and C that are automatically
installed with the Python interpreter. Although Python itself provides
an easy-to-use scripting language, much of the real action in Python
development involves this vast library of programming tools (a few
hundred modules at last count) that ship with the Python
package.
In fact, the standard library is so powerful that it is not
uncommon to hear Python described as
batteries
included
—a phrase generally credited to Frank
Stajano
meaning that most of what you need for real day-to-day
work is already there for importing. Python’s standard library, while
not part of the core language per se, is a standard part of the Python
system and you can expect it to be available wherever your scripts
run. Indeed, this is a noteworthy difference between Python and some
other scripting languages—because Python comes with so many library
tools “out of the box,” supplemental sites like Perl’s CPAN are not as
important.
As we’ll see, the standard library forms much of the challenge
in Python programming. Once you’ve mastered the core language, you’ll
find that you’ll spend most of your time applying the built-in
functions and modules that come with the system. On the other hand,
libraries are where most of the fun happens. In practice, programs
become most interesting when they start using services external to the
language interpreter: networks, files, GUIs, XML, databases, and so
on. All of these are supported in the Python
standard
library.
Beyond the standard library, there is an additional
collection
of
third-party packages
for Python
that must be fetched and installed separately. As of this writing, you
can find most of these third-party extensions via general web
searches, and using the links at
http://www.python.org
and at the PyPI website
(accessible from
http://www.python.org
). Some
third-party extensions are large systems in their own right; NumPy,
Django, and VPython, for instance, add vector processing, website
construction, and visualization, respectively.
If you have to do something special with Python, chances are
good that either its support is part of the standard Python install
package or you can find a free and open source module that will help.
Most of the tools we’ll employ in this text are a standard part of
Python, but I’ll be careful to point out things that must be installed
separately. Of course, Python’s extreme code reuse idiom also makes
your programs dependent on the code you reuse; in practice, though,
and as we’ll see repeatedly in this book, powerful libraries coupled
with open source access speed development without locking you into an
existing set of features or limitations.