Why do we Python programmers stay so annoyed with JavaScript's broken this keyword? After all, every programming language has rough edges. The problem with this even turns out to be easy to work around once you learn the knack. So why does it feel like JavaScript has committed a fresh offense every time we trip over it?

The answer, I suggest, is that JavaScript manages to disturb very deep mental scaffolds with the behavior of the this keyword. Not all programming language annoyances are created equal. Some involve inconsistency within a language itself, when a pattern set up by one feature is broken by another (think of method names in the Python Standard Library). More serious issues can involve hassles with a language's syntax or poor behaviors within its type system. But in this case JavaScript decided that it would abandon a key property of the system that lies beneath it — that it would break the conventions that, in fact, underlie all programming languages.

JavaScript decided that it would break mathematics.

Let me explain by starting with a simple example. You are already familiar with operator precedence, and how multiplication binds more tightly than addition when both operators appear in the same expression. In the following expression, a will first be multiplied with b, then the result of that operation will be added to c.

There is, in other words, a hidden intermediate result inside of this equation: the result of the multiplication. So (1) is, in fact, a shorthand for writing this sequence of two separate binary operations:

Note that our ability to transform (1) into the pair of lines (2) does not involve any special properties of the operators themselves. This does not illustrate some special feature of multiplication or addition, like the Distributive Property! Instead, we are working down at the lower and more fundamental level of asking what a complex math expression even means. So while we must use argument and proof to learn that addition is commutative, the operators and their precedence are simply a matter of definition — of what we decide it means when we string symbols together to form an expression in the first place.

Now it turns out that the familiar programming language idiom of calling a method in a language like Python or JavaScript is quite precisely analogous to expression (1), because it separates three symbols with a pair of binary operators, where the left operator binds most tightly:

(3)   n = a.b(c)

Until a programmer really grasps what it means for a language to have “first-class functions” — functions that can themselves be manipulated as values — it might be difficult to see that a.b makes quite good sense simply standing by itself. It means “take the a object, look and see whether it has an attribute named b, and resolve the value of that attribute.” And so a.b works perfectly in front of (c) so long as the result of the attribute lookup happens to return a callable.

So expression (3) can be decomposed like expression (1), and in Python the following two steps are exactly equivalent to statement (3) — except, of course, for defining an extra local variable fn:

(4)    fn = a.b
       n = fn(c)

This is, again, simply a property of how expressions work in math — of the fact that you ought to be able to compute intermediate results by pulling an expression apart into its constituent binary operations. But, alas, JavaScript decided to break this property of expressions, and makes extra invisible magic happen when the two operators are used in combination — magic that does not happen when they are separated into separate steps. Or, perhaps there is a more interesting way to think about it:

/* In JavaScript this is NOT a pair of binary operations. It is a SINGLE
   ternary operator that, to sow confusion among programmers, happens to
   use the same symbols as two well-known binary operations. */

a.b(c);

/* This ternary operator is roughly equivalent to: */

var fn = a.b;
var old_this = this;
this = a;
fn(c);
this = old_this;

Younger programmers, for whom a.b(c) is simply a gesture, may find our distaste for JavaScript's behavior inexplicable. The problem is worst for the experienced programmer or mathematician, who — every time she types it — remembers what the dot and parentheses really mean as clean and separate operations, but has to remember that their meanings change when they appear in combination. This semantic instability flaunts a very long tradition of defining math operators so that expressions can be composed together and broken down again without changing their meaning.

And that, I think, is why it annoys us: because from early grade school through college we have learned that math expressions compose and decompose cleanly, and JavaScript takes that symmetry away.

One last note for newer Python programmers reading this: you might be suspecting that Python itself has some kind of magic involved here, because how else could it remember later whether you had pulled method fn off of the specific object a instead of off some other instance of that class? The answer is that every lookup of an instance method returns a new object, called a bound method, that remembers the object on which the lookup took place.

>>> class C:
...     def __init__(self, n):
...         self.n = n
...     def __repr__(self):
...         return 'C%d' % self.n
...     def fn(self, m):
...         return self.n + m
...
>>> a = C(100)
>>> b = C(220)
>>> a.fn
<bound method C.fn of C100>
>>> b.fn
<bound method C.fn of C220>
>>> b.fn(5)
225

What about your own least favorite language features, whether in JavaScript, Python, or something else? Are they all simply about scruples and inconvenience? Or can you identify some deep-seated assumptions of your own mental scaffolding that keep ruining your experience with a specific language? Let us know in the comments!

By this time tomorrow I will doubtless be wearing swimming trunks — in northern Ohio — in winter — while listening to people rave about Java and C# and Ruby and wondering what I have gotten myself into. I will be at CodeMash, a conference that was started by developers who wanted an event that focused solely on the programmer while including a wide range of languages and technologies.

It was lucky that I signed up the moment that CodeMash 2012 registration opened back in October, because the 1,200 conference tickets sold out in only 20 minutes — no event in the Python community had prepared me for that kind of demand!

I learned about CodeMash conference from its co-founder Brian Prince when we were fellow speakers at PyOhio last July. So why did a Python programmer like me decide to attend?

• Even though the technologies that Brian chooses are different from mine, he is clearly animated by the same passion for combining good code with good community. If his co-founders are at all like him, then I knew that a great event was in the works.
• I want to learn another conference's culture. For example, I was stunned to see strong suggestions on the CodeMash mailing list that attendees should not carry laptops — instead, they recommend pencil, paper, and something they call Sketchnotes. Since good teachers have a reflex that makes them try to bring the whole audience along with them as they make a point, we could actually be slowing up PyCon speakers when half the audience is face-down typing and clearly a half step behind what is being said.

• I could predict that moving to Bluffton, Ohio, as winter descended would leave me with very few opportunities to meet other developers. After several weeks of being the only programmer I know, a large regional conference will let me bask in the company of other people who understand what I do for a living.
• It is too easy to judge other languages by what I think are drawbacks in their design, or by the poor code that most programmers produce whatever their language. I want see what excites the real experts who solve interesting problems using Java, Ruby, and C# — people who use those languages to the hilt, and do a great job of it.
• Being evangelized by smart people is interesting and humbling, if you let down your guard and really listen. And hearing Ruby and C# people explain the glories of their languages will remind me of how I must sound when I hold forth on the advantages of Python, or Emacs, or Vibram Fivefingers.

• Brian wants to make CodeMash more popular for Python programmers — and a few luminaries like Bruce Eckel, Mike Pirnat, and Mark Ramm are already on the schedule this year. Next year I might offer to speak. But first I wanted to show up and just listen, figure out the vibe of the conference, and learn more about what is happening outside of the Python community.
• Finally, it does sound like great fun: eating, drinking, and being merry at an indoor water park resort in the middle of an Ohio winter. Kalahari, here I come!

(Images are Creative Commons licensed from Flickr photographers iriskh and Alan.Barber.)

(My official Concentric CSS “style.css” is in a GitHub repository)

Perhaps my mind is unusually visual, but I have no idea how people clearly picture the effects of their CSS rules when following the common advice to sort their properties alphabetically within each declaration block (as in the answers to this Stack Overflow question).

The main alternative to alphabetization seems to be a CSS property order that claims to be based on the box model but which tackles properties in a sadly haphazard order. It starts with display and position, which are a great start, but these are immediately followed by the height and width — even though these dimensions only apply to the content, which is nestled down inside the deepest level of the box! The order then continues to skip around wildly, jumping outside the box to talk about the margins, then jumping almost all the way back inside to talk about the padding. Finally it gets to the borders, even though they will actually be sandwiched between the margins and the padding when rendered by the browser.

For reference, here is the box model as illustrated in the CSS standard itself:

The fact that width and height apply only to the content, and not to the padding or anything else, is a crucial issue in CSS — an issue that causes newcomers a lot of grief. For everyone's sanity, I need the order in which I declare properties to reflect the structure of the box itself, with the width and height coming after the decorations that wrap around them.

I call the result Concentric CSS and the basic template looks something like this:

{
    display: ;    /* Where and how the box is placed */
    position: ;
    float: ;
    clear: ;

    visibility: ; /* Can the box be seen? */
    opacity: ;
    z-index: ;

    margin: ;     /* Layers of the box model */
    outline: ;
    border: ;
    background: ;
    padding: ;

    width: ;      /* Content dimensions and scrollbars */
    height: ;
    overflow: ;

    color: ;      /* Text */
    text: ;
    font: ;
}

Are you surprised that I sandwiched background between the border and padding instead of saving it until later? My reasoning is that the padding is the first part of the box that actually gets painted with the background color — I have positioned background so that everything beneath it gets the background color, while everything above has its own color (borders) or is transparent (margins).

I am not certain about my choice of where to place the overflow property. Its current position is dictated by the fact that it is often triggered by too small a height and width — so it often serves as a kind of “else clause” to say what should happen if the height and width are too constraining, and so the property makes sense next to them. But one of the consequences of overflow can be that scrollbars appear around the box, and an argument could be made for putting overflow up between the borders and padding, because that is exactly the place where the standard insists that scrollbars be drawn.

For the sake of completeness I have written up my preferred property order — with a much more exhaustive list of properties than in the sketch shown above — as a style.css file that lives in its own GitHub repository. I welcome comments and improvements, especially ones that will make this ordering an even better reflection of the box model. I want my CSS to make as much sense as possible both to the newcomer as well as the seasoned professional!

The Compass CSS authoring framework has become one of the standard tools that gets installed when I start working on a new web application. I always version-control not only the .scss Sass source files that I myself write, but also the .css CSS files that Compass compiles from them. That way, anyone who checks out the project immediately gets a working web site without having to install Compass — or even having to know that it exists, if they are not themselves involved in writing the CSS.

But those of us who work on the CSS do need Compass, so I have a standard technique that I copy from project to project that installs Compass into a small, local Ruby environment, providing the same kind of isolation and reproducibility that Python has taught me to know and love thanks to virtualenv.

The process goes like this.

First I create a compass/ directory, typically up at the top level of the project, that initially contains nothing but a pair of shell scripts. The first script, install.sh, knows how to get Compass downloaded and installed:

#!/bin/bash
# compass/install.sh - install Compass under the "./Gem" directory

if ! which gem >/dev/null ;then
    echo 'Error: no "gem" command available'
    echo 'Please "sudo aptitude install rubygems1.8" or "ruby1.9.1"'
    exit 1
fi
BASE=$(dirname $(readlink -f $(which "$0")))
cd $BASE  # the directory where this script lives
gem install -i Gem compass
gem install -i Gem compass-susy-plugin

When this shell script is run, a compass/Gem/ directory gets created with the compass command down inside of it. To let me forget where the binary is located and how it can be safely invoked, a second shell script named compass.sh wraps up the details:

#!/bin/bash
# compass/compass.sh - properly invoke the "Compass" program

BASE=$(dirname $(readlink -f $(which "$0")))
export GEM_HOME=$BASE/Gem
export RUBYLIB=$BASE/Gem/lib
$BASE/Gem/bin/compass "$@"

I always tell my version-control system to ignore the compass/Gem/ directory and the 5,115 files that Ruby creates beneath it; instead, I simply remember to re-run install.sh after each fresh checkout when I want to get to work on the CSS.

When I first start a project, I need an initial set of .scss files to start editing, which can be supplied through the Compass command create. Usually I want the CSS output to be written somewhere outside of the compass/ directory, so my initialization steps go something like this:

$ cd compass/
$ ./install.sh
$ ./compass.sh create
$ rm -r stylesheets/    # where Compass wanted the output CSS!
$ emacs config.rb
# There, I adjust the line: css_dir = "../webapp/static/css"
# Plus, I also tend to set: line_comments = false
# Of course, use your editor-of-choice for this step!

I check into version control the config.rb file and the compass/src/ directory of pristine .scss files. I tell my version-control system to ignore the .sass-cache/ directory that gets created inside of compass/ each time the CSS is rebuilt.

Once those changes checked in, I never need to run the create command again for the whole lifetime of the project. Instead, whenever I am ready to work on the CSS, I simply open the .scss files in my editor and in another window I do this:

$ cd compass/
$ ./compass.sh watch

Just as a good development web server will auto-restart when you finish editing a file and hit Save, the Compass watch command will sit patiently all day and re-compile your Sass files to CSS whenever it sees you change them. By leaving it running, I can edit a .scss file and then hit Reload in my browser almost immediately to see the result without having to stop and run any intermediate commands.

The files, therefore, that wind up in my version control are these:

compass/compass.sh
compass/config.rb
compass/install.sh
compass/src/_base.scss
compass/src/_defaults.scss
compass/src/ie.scss
compass/src/print.scss
compass/src/screen.scss

And, of course, I also version-control the CSS files that Compass writes as output, over where I put them in the “main directory” of my web application:

webapp/static/css/ie.css
webapp/static/css/print.css
webapp/static/css/screen.css

This all works out extremely well. Normal developers and deployers look under the webapp/ directory and see what looks like normal, if preternaturally well-written and organized, CSS files exactly where they expect to find them. Only we CSS geeks on the project know that they are written by shuffling over to the Compass directory and firing up a program that compiles them from simpler source files. And thanks to my handy little pair of shell scripts, the Compass install itself is always completely automated.

Of course, as you can tell from the error message that install.sh prints if it cannot find Ruby, these scripts are aimed at an audience using Ubuntu or Debian. Please note in your comments to this post how you might expand those instructions to help people using Fedora, MacOS X, or other operating systems!

Today I got stuck between a rock and hard place — or, more specifically, stuck between the assumptions of Robert Brewer and those of Ian Bicking. In case you ever try mounting a WSGI application underneath a larger CherryPy application, here is the story.

# Easy: putting a WSGI `app` behind the CherryPy HTTP server

server = CherryPyWSGIServer(('0.0.0.0', 8001), app, numthreads=30)
server.start()

# More interesting: mounting `app` beneath a particular URL path
# This works, but `app` gets no logging or error handling

cherrypy.tree.graft(app, '/api')
cherrypy.tree.mount(None, '/static', {'/' : {
    'tools.staticdir.dir': static_root,
    'tools.staticdir.on': True,
    }})
cherrypy.engine.start()
cherrypy.engine.block()

$ pip install flup
Downloading/unpacking flup...
$ python -c 'import flup.middleware'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named middleware

$ pip install wsgilog
Downloading/unpacking wsgilog...
ImportError: No module named ez_setup

# Transform bare `app` into one that logs and 500s on exceptions

from paste.exceptions.errormiddleware import ErrorMiddleware
from paste.translogger import TransLogger

app = ErrorMiddleware(app, debug=debug_flag)
app = TransLogger(app, setup_console_handler=debug_flag)

# Now we proceed as before to build our CherryPy application.

cherrypy.tree.graft(app, '/api')
...

# from paste/exceptions/errormiddleware.py

class ErrorMiddleware(object):
    ...
    def exception_handler(self, exc_info, environ):
        ...
        return handle_exception(
            exc_info, environ['wsgi.errors'],
            ...)

# from cherrypy/wsgiserver/__init__.py

class WSGIGateway_10(WSGIGateway):

    def get_environ(self):
        """Return a new environ dict targeting the given wsgi.version"""
        ...
        env = {
            ...
            'wsgi.errors': sys.stderr,
            ...
            }
         ...
         return env

# Adding three middlewares: error, logging, and my own

app = ErrorMiddleware(app, debug=debug_flag)
app = TransLogger(app, setup_console_handler=debug_flag)

errlog = open('http-tracebacks.log', 'a', 0)

def app2(environ, start_response):
    environ['wsgi.errors'] = errlog
    return app(environ, start_response)

cherrypy.tree.graft(app2, '/api')

What was my big idea? That in printed Python code, indentation should be visible.

Any of you who have had to read many Python listings printed in books will immediately recognize the problem that I wanted solved. When a listing is long enough to run on to a second page, it is often less than clear whether the code there is continuing at the same level of indentation, or whether the page break has just happened to correspond to a point in the code where it dedented out to the previous level. Languages with braces or explicit “end” statements to close blocks never have to worry about this. But in Python — especially where a script or code snippet ends without ever returning to the outermost level of indentation — the last few lines of the script feel as though they are left hanging if they stand alone at the top of a new page of text.

Of course, there were several practical considerations that had to be settled. A symbol for indentation had to be chosen, for example. I selected the Unicode double-chevron because it is a character that is never valid in actual Python code. Then the publisher had to be convinced to try the experiment; it helped that I had the full support of my editor, Laurin Becker, who also prepared the layout people for the fact that these chevrons were not part of the code and would need to remain visually distinct from it. Finally — because I had no desire to insert and color each chevron by hand — I had to write an lxml script to insert the chevrons into my OpenOffice documents, then go back and ruefully remove by hand the chevrons that got nonsensically inserted into snippets of other languages like HTML.

But now I want to hear what readers think! I have not yet seen a review that mentions whether the visible indentation helps, hurts, or is simply irrelevant to the Python listings. If you happen to have seen the new edition of Foundations of Python Network Programming, let me know what you think. While creating the effect cost some time and effort, I will happily do it again in my next book if turns out to have actually helped readers scan the program listings.

Over the years I had already built a stable full of shell functions for doing grep(1) and find(1) in various combinations, and my functions even defaulted to using pcregrep(1) when available because Perl-style REs (which have nearly the same format used by Python) seem to require so many fewer backslashes for common cases. It hardly seemed worth the effort to move to another tool — and the grin output format seemed glarish and offensive at first glance, not at all like the austere output of traditional grep:

$ pip install grin
$ cd Python-3.2b2
$ grin autoGIL
./Doc/whatsnew/2.6.rst:
 3167 :   :mod:`autoGIL`,
./Misc/HISTORY:
 5577 : - There's a new module called "autoGIL", which

But I forced myself to try using it again a few weeks later, and when actually doing real work I could not help but notice that the results were far easier for my eyes to scan than grep output. This is an important point: so often, the issue of whether something looks like it will be easy to read is a quite different matter than whether it is actually difficult to read the moment you stop looking at it and start trying to look through it to see your data! Now I can clearly see where the output from one file ends and the next begins — which traditionally is quite difficult if you are looking through a series of files with very similar names. Long file paths no longer push matching lines to the right, splitting them across the right edge of my standard 80-column terminal window. In fact, one of my first objections to its layout had been the line consumed by each stand-alone file name; but in practice, I found, far more lines are gained because of the matches that are not split across the right edge.

You can run grin against individual files or directories by naming them on the command line; adjust the set of files to which it pays attention; and even revert its output to a traditional file:line format if you want to pass the output to another program. You can, in other words, ask it to behave more like traditional grep. But its default behavior, I gradually realized after running it several hundred times, is by far the most common way that I had been using grep anyway — to search the source files beneath my working directory for a pattern.

The author, Robert Kern, has answered emails promptly and was happy to accept a few patches. I now have a shell script that I run whenever I set up a new Unix account that builds a virtual environment, includes its bin directory in my PATH, and installs grin as one of the most important Python tools that I need always at my fingertips. Try it out!

My long labor is at last at an end: Apress has published my rewrite of John Goerzen's Foundations of Python Network Programming (2004) and I have released the example programs as both Python 2 and Python 3 code in a Bitbucket repository and also as a zipfile on the Apress web site. I can finally return to more casual writing — this is my first blog post in many months! — and can be more active in Python projects again.

I was amazed, as I studied the book's popular first edition, at how far Python has come since 2004. None of the modern Python web frameworks existed; the book offered one chapter on CGI programming, another on mod_python, and never even mentioned Zope. Python 2.3 was the most recent version of Python. The book could cite FTP as one of the “most widely used protocols on the Internet.” Parsing HTML involved stepping through the markup with HTMLParser and the recommended approach to processing XML was the awkward xml.dom. JSON was not yet popular enough to even warrant mention. The author recommended the dependable syslog module over the newfangled logging package in the Standard Library, and remote administration tools like paramiko and fabric either did not exist or were not yet on the radar.

Looking back, it appears that 2005 — the year following the first edition's publication — was a turning point for Python web technology in particular. CherryPy saw its first release in late 2004, and over the next year we were introduced to Django, Pylons, and Turbogears, all on the heels of the Ruby on Rails “framework” phenomenon. And both of the web scraping technologies covered in my new edition of the book, BeautifulSoup and lxml, also came out in 2005. In the face of all these changes, the web chapters received a full rewrite based on the latest technology.

I also rewrote the introductory chapters so that UDP and TCP each get their own chapter, focused on the protocol itself, instead of leaving the information about each protocol split between a client socket chapter and a server socket chapter. I have replaced the separate chapters on forking, threading, and event-driven servers with a single chapter that takes an example network server, rewrites that same server six different ways — including Twisted and a raw polling event loop — and then uses funkload to study the resulting performance. And even though an editor objected that it lacked unity, I insisted that a chapter be dedicated to memcached, message queues, and map-reduce, since they are so important to scaling modern Internet services.

Apress had already slated the project for Python 2 based on the advice of a well-known Python programmer, and I heartily supported his recommendation. His wisdom is bourne out by the result: as you can see from the README.txt that I included with the source code bundle, fully one-quarter (22/86) of the programs will simply not run today under Python 3 because of missing dependencies. I see this new Foundations of Python Network Programming as the perfect companion for Python 2.7 — which was released as I was writing — since the book will bring you up to date with the final features of the Python 2 series and the third party libraries that support it.

I enjoyed working with the Apress team; Laurin Becker is a great managing editor who was always on my side, and Michael Bernstein as technical editor gave great feedback which made this an even better book. There were only two annoyances that I encountered with the book's release. First, as the accompanying image illustrates, Apress used a much more compact layout than in the first edition. This not only makes the book appear much shorter than its predecessor, but also makes it (to my eyes) visually crowded and more tiring to read. Second, Apress was not prompt about changing the project title after their decision to target Python 2, with the result that Amazon had “Python 3” in the title all the way through the book's release in late December — resulting in 1-star reviews for the first few weeks!

I will, by the way, soon be blogging about my experience rewriting the book's example code to work under Python 3. This should help two groups of people: anyone porting a Python 2 network application to Python 3 will probably run into the same issues I did; and people who are already experimenting with Python 3 will want to know how to apply the book's techniques to the newer version of the language.

Feel free to submit questions about the book or its example programs to the Bitbucket source code repository where the code is stored. The revision took far more effort than I had expected, but I am very happy to have found a format into which I could distill so much of my own — and the Python community's — network programming experience, so that it will help programmers for years to come. Enjoy!

IOError: [Errno 24] Too many open files

An lsof against the process confirmed that more files were open after every restart. My guess was that leftover references were keeping a few Python file objects alive from one CherryPy reload to the next, and I remembered having once used a neat utility for exploring the object heap. After some investigation I re-discovered that it was Heapy. So I added a pdb breakpoint, did some investigating, and was puzzled to find that after each restart only four Python file objects existed — one for each log file in our application.

(I also tried using objgraph, which is far easier to use than Heapy, but it could not tell that there were file objects in memory at all. I have no idea why.)

Well, this was a puzzle. How could the number of open file descriptors increase without bound when Python was clearly deleting all of the old file objects? The answer, once I finally tried reading the source code to the Autoreloader plug-in, was of course very simple: CherryPy performs each restart by doing an exec() to completely wipe out the process image and replace it with a new instance of the CherryPy application. Which is certainly a very thorough approach! Except for one thing: file descriptors in Unix are set, by default, to survive an exec() call, but the new instance of Python that spins up inside of the process does not know that they are there, so they never get closed. It appeared that suddenly calling ØMQ out of existence with an exec() also left a few sockets lying around.

Several possible solutions came to mind. What if a more thorough effort was made to delete all Python objects before running the exec() call? That sounded daunting, though — it might take a lot of effort to march through all of the application object trees closing everything down. I could have focused my efforts just on finding the file objects, but that approach felt fragile; what would happen the next time one of our developers wrote a new module that opened a log file?

Monkey patching the open() built-in to create files with their close-on-exec flag already set is, of course, too terrible a solution even to contemplate.

In the end, the simplest solution seemed to be the creation of a little CherryPy plug-in that, as the very last shutdown action, would loop over all existing file descriptors and set their close-on-exec flag. Here is the plug-in, in case the pattern helps anyone else:

"""Make sure file descriptors close when CherryPy exec's."""

import os
import sys
from cherrypy.process.plugins import SimplePlugin

class CloexecPlugin(SimplePlugin):
    def stop(self):
        if hasattr(sys, 'getwindowsversion'):
            return
        import fcntl  # not available under Windows
        max = os.sysconf('SC_OPEN_MAX') if hasattr(os, 'sysconf') else 1024
        for fd in range(3, max):  # skip stdin/out/err
            try:
                flags = fcntl.fcntl(fd, fcntl.F_GETFD)
            except IOError:
                continue
            fcntl.fcntl(fd, fcntl.F_SETFD, flags | fcntl.FD_CLOEXEC)

    stop.priority = 99

Of course, I suspect that this problem was happening all along, even before we added extra logging and then integrated ØMQ into our application. But back then, with maybe only one or two stray file descriptors surviving each restart, it would have taken five hundred or a thousand CherryPy restarts for the problem to be noticed — and, apparently, none of us developers ever reached that impressive total. Now we know to be careful!

Several images disappeared from the Our Fresh World green-building web site because Google changed their Picasa API recently — and I must not be subscribed to the proper mailing list or blog to have been warned ahead of time. Where are incompatible Google API tweaks announced?

The site owner and his photographer use Picasa web albums to upload, edit, and maintain their image collection. They simply give special tags to their favorite photos, and my application code then knows that it is supposed to display those photos on the web site. I almost used Flickr for this application, both because I am an avid Flickr user myself and because I consider its web interface more usable. But, perhaps predictably, Picasa had the much stronger search API — whereas you can either ask Flickr for the photos in a particular set, or ask for all of someone's photos that share a particular tag, Picasa lets you can combine the two queries and ask for only the photos that are in a particular set and that also share a specific tag. And since search is what attaches pictures to this web site, Picasa was my choice.

All was going well, with each page getting populated by searches like:

http://picasaweb.google.com/data/feed/api/user/name
?kind=photo&tag=solar-power

Then I received an email from the site owner, complaining that many of the photographs had disappeared! After seeing some complaints in the Picasa forums about recent versions of the user interface treating certain “special characters” in tags as spaces instead, I suddenly wondered whether the hyphen in several of our tags (like the “solar-power” tag in the URL above) was the cause of our trouble. I adjusted my code so that this search became:

http://picasaweb.google.com/…?kind=photo&tag=solar+power

And, voilà, the images returned and were again visible! Does anyone know what forum or blog I should have been following to be informed of this critical change by Google? It is dismaying to have a site break in front of a customer when the very reason that I chose a Google product was because of their powerful API for integrating my application.