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.)

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!

But then, eventually, one has to write the actual review.

And so, a full four months after that friendly email from Packt Publishing, it is time that I sit down and put together some thoughts about Carlos de la Guardia's first book, Grok 1.0 Web Development. Carlos is a long-time veteran of the Zope and Plone communities, and Grok, of course, is the web framework that places a simple and agile convention-driven engine atop the otherwise notoriously XML-ridden Zope application framework. Grok is an important project, because it packages the technology of Python's oldest and most experienced community of web developers in a way that makes it easy to extend and use.

First, one notices that the book does exhibit the kind of typos for which Packt are well known; but not so many, in this case, as to distract me from the text. The book tackles increasingly complicated topics in roughly the same order as every book in the web development genre: first installation, then views, models, forms, and so forth. But even here one notices an initial difference! Because this is the land of Zope, the search engine chapter appears quite early in the book — in Chapter 6, in fact. While some web frameworks can only support search through the installation of a special database extension, or perhaps through an entirely separate third-party application, Grok comes with search already integrated into its object database. This lets the concept be introduced early as a natural part of the framework, rather than being a difficult exercise in product integration best left for after the user has learned deployment.

Not that third-party products are bad! In fact, I am happy to see that in many cases Carlos teaches his readers to use them. Barely twenty pages into the book, the new developer is being taught about using virtualenv to maintain an installation of Python packages; and near the end, Carlos teaches deployment using the modern and sleek mod_wsgi module. Some books feel myopically focused on one software community; this one, instead, feels expansive, a place where best practices from all across the Python ecosystem meet.

It is particularly notable that at one point Carlos steps outside of Zope entirely and, for an entire chapter, describes how Grok integrates support for relational databases through SQLAlchemy, Python's most outstanding ORM. This both reflects credit upon the flexibility of Grok — whose abstractions must be working extremely well to build atop an entirely different database model, one that is not even native to Zope — and it evidences Carlos's determination to teach a very wide set of skills in his book. In fact, he even goes in the other direction at one point, and teaches the interested developer how to use the ZODB without Grok in case they want to access it from another application!

The book tends to be quite clear in what it explains, but it sometimes feels as though a few more side trips in its examples would be welcome — it was not always clear to me whether a beginner, after plowing through an example, would understand what alternatives Carlos faced at each step, and why Carlos chose to build the solutions in the way he did.

Though the book does cover testing, it is not test driven — testing is confined to its own chapter near the end of the book, rather than motivating the design of each sample application. A more interesting omission is that the book says nothing about web services, despite the fact that XML-RPC and REST are two things that Grok does particularly well! A chapter on building web APIs would be a great subject for a second edition of this book, especially if it then proceeded to show how easily Grok can support the Ajax design pattern.

It did strike me as decidedly old-fashioned that Carlos repeats the weary canard that the Zope template language's awkwardness and verbosity are worth it, because it allows your templates to remain valid HTML, because your designers might, at any moment, want to open up and tweak a raw template in their browsers! This, of course, only works if your templates are each an entire page — if you fail to avail yourself, in other words, of any of the power of the macros, slots, and viewlets that Carlos goes on to describe later. And, in fact, many of his later templates are indeed mere un-styled HTML snippets that no designer in their right mind would view in isolation. All of which leads to the question of why Genshi, another template language popular with Grok developers, does not warrant any mention in the book — especially since the book in so many other cases is careful to mention more widely deployed Python technologies that Grok is able to use.

Finally, I can attest that a concept I never managed to learn when I was active with Grok — the tangle of concepts that surround viewlets, viewlet managers, layers, and skins — became quite clear as I sat down and read Chapter 8 in close detail. On the one topic which I could truly approach as a newcomer, therefore, I found Carlos's approach to be very direct and understandable.

Grok has good online documentation, but unless you are already an experienced developer you will have difficulty putting the pieces together into a story that runs smoothly from model to view to deployment. If you need help getting the whole picture of how Grok apps fit together, you will certainly want this book. You can purchase it from either Amazon or directly from its publisher, Packt Publishing.

I have wanted to try the multiprocessing module out for some time, and now have a consulting project that will really benefit from multiple processes: they will let our application run third-party plugins without having to worry that any bugs or indiscretions which they commit might damage or hang our main server, which can remain safe in another process.

First, one can only stand in awe at the achievement — and the amount of work — that the multiprocessing module represents. I cannot imagine the time that it would have taken our team to figure out all of the differences between Linux and Windows when it comes to processes, shared memory, and concurrency mechanisms. In fact, the approach we are taking might not even have been feasible under those circumstances. By figuring out how to get locks, queues, and shared data structures all working cleanly on such different architectures, the multiprocessing authors save Python programmers out on the street like me from reinventing a dozen wheels when we need to support multi-platform concurrency.

Well, almost.

There is one rather startling difference which the multiprocessing module does not hide: the fact that while every Windows process must spin up independently of the parent process that created it, Linux supports the fork(2) system call that creates a child processes already in possession of exactly the same resources as its parent: every data structure, open file, and database connection that existed in the parent process is still sitting there, open and ready to use, in the child. Consider this small program:

from multiprocessing import Process
f = None

def child():
    print f

if __name__ == '__main__':
    f = open('mp.py', 'r')                                                      
    p = Process(target=child)
    p.start()
    p.join()

On Linux, the open file f keeps its value in the child process; the child has inherited an open connection from its parent:

$ python mp.py
<open file 'mp.py', mode 'r' at 0xb7734ac8>

Under Windows, however, where the multiprocessing module has to spawn a fresh copy of the Python interpreter to which it gives special instructions to just run the function f(), the module is a clean slate without an open file inside:

C:\Users\brandon\dev>python mp.py
None

Now, my complaint is not exactly that the multiprocessing documentation is misleading on this point; under its section on Programming guidelines, it makes it quite clear that:

On Unix a child process can make use of a shared resource created in a parent process using a global resource. However, it is better to pass the object as an argument to the constructor for the child process.

I have no quarrel with this advice; if I am careful to pass everything the child needs in its list of arguments, then I can be sure that my code will work under both Linux and Windows.

But I do wish that the multiprocessing module provided more support for testing this condition more rigorously under Linux. In particular, I wish that there were some way of turning the simple forking logic off — of saying, “Yes, I know that Linux will let you create a child process very simply using fork(2), but for my sanity would you please create the child process from scratch like you do under Windows so that I can test whether my code accidentally depends on residual state from the parent process that I did not see that I was using?” I looked at the multiprocessing "forking.py" module to see whether I could turn on the Windows-style process spawning even from inside of Linux, but the mechanism is chosen by a bare module-level check of "sys.platform" and if I overwrite that variable with 'win32' the code then dies when it tries to import "msvcrt" which is available only under Windows.

There is, thus, even in principle, no way that I can test my multiprocessing application under Linux which will give me any assurance that my child processes are not accidentally taking advantage of data structures and open connections left lying around by the parent process; only by actually moving over to Windows itself can I see how my child code really behaves on its own. I have created a feature request in the Python bug tracker to see whether this situation can be improved.

But even with this one inconvenience — which is troubling me much less, now that I at least understand why my application was behaving so differently under Windows — the multiprocessing module is still a huge leap forwards for Python programmers who need to run code in heavyweight processes with all of the isolation and safety that they provide. Thanks again to Jesse and the multiprocessing team!

How can a collaborative site like ours best be edited and updated? Well, I would like to report some modest initial success with an experimental approach: I now maintain the site as a Sphinx-powered documentation system stored in a BitBucket repository into which I pull changes made by my collaborators. The advantages are several.

• The change management tools supported by traditional CMS systems, even at their best, seem somehow anemic when compared to the toolkit provided by a good DVCS like Mercurial. Where, for example, does even a capable CMS like Plone provide anything like Mercurial's “backout” or “blame” commands?
• Markup as well-designed as reStructuredText is not only a lot of fun to use, bit it also very cleanly separates content from design. Authors working in plain text tend to produce clean, readable content without the messy markup often associated with visual HTML editors, or, worse yet, the disaster that is Microsoft Word.
• Staging — a feature I find essential, but which seems missing from many default CMS configurations — occurs automatically! Each author can see locally how the site will look with their changes, and after doing a pull I can review the site's appearance on my laptop before finally deploying the new content to the production site.

To top it all off, authors get to use their own editor-of-choice when making contributions, and we all get extra practice cloning and merging in my favorite DVCS. I am optimistic about this direction, but I will post again if we wind up hitting snags in the future. Finally, of course, feel free to clone our repository if you want to see how Sphinx looks when running a generic web site.