bor.borygmus

It’s time now to write about two of my favorite pieces of software ever written: Georg Brandl’s Sphinx and Pylons’ Pylons. Normally, these get along like a house on concrete, which is to say very well. A Pylons web application is a well-behaved, standard Python package that pays all the taxes: a setup.py, no module magic like pre-modern Django, and imports as expected. However, if you have ever used the highly useful Sphinx autodoc extension and have pointed it at a module in your Pylons app, you may have run into a traceback that looks like this:

[snip]
File "[snip]/autodoc.py", line 1019, in can_document_member
  return (isdescriptor(member) and not
File "[snip]/autodoc.py", line 203, in isdescriptor
  if hasattr(getattr(x, item, None), '__call__'):
File "[snip]/paste/registry.py", line 137, in __getattr__
  return getattr(self._current_obj(), attr)
File "[snip]/paste/registry.py", line 194, in _current_obj
  'thread' % self.____name__)
TypeError: No object (name: url) has been registered for this thread

Two questions should emerge immediately: What is paste.registry? And why is it throwing a traceback?

Ian Bicking’s Python Paste jar of goods (and WebOb) is a testament to having a standardized web application protocol like WSGI. Rather than making the hard choice between starting with a framework like Django or starting from scratch, we can a mix and match libraries and build our fully-customized stack, all the while learning about Python web development and each other and our bodies and so on. For example, suppose Bill is on line three, screaming down your ear about choosing a WSGI development server by the end of this hour, dammit so everybody can deploy applications in a uniform way. Your first instinct is to, of course, grab madly at Paste Script, which takes a Paste Deploy configuration file and dutifully runs applications like nobody’s business.