This post started as a comment to Michael Rooney's question: Failing tests: When are they okay?, and then it became a bit too long for a comment.

I've an opportunity to get to know Pylons. Here's an unsorted list of first (and second) impressions:

• Pylons has great documentation, though I did stumble upon a few broken links
• Pylons has a great development environment (instant and automatic server restarts; interactive Python console in your web browser on errors)
• It seems that nobody using Paste is interested in logging the startup and shutdown time of the web server
• SQLAlchemy overwhelms with TMTOWTDI
• zc.buildout can be replaced by a 4-line shell script using virtualenv and easy_install; this will save you headaches
• setuptools is made of pure crazyness, but we can't live without it

These aren't directly related to Pylons:

• distributed version control systems are great for throwaway prototypes (especially when you want to compare several ways to do it)
• non-distributed version control systems aren't
• py.test is weird and takes some getting used to, but has some nice properties as a test runner; shame about breaking compatibility with unittest
• automated functional tests for system deployment in a freshly cloned Xen virtual machine are cool, albeit slow-ish

Update: About the naive notion that using easy_install instead of zc.buildout would help me avoid headaches? Muahahahahaha. Ha. Haha. Muahhaaaaaa. Wrong.

Also, TMTOWTDI is maybe too strong a word for SQLAlchemy's plethora of choices. And you really want to be using 0.5. And Pylons is even more awesome than I first thought. Obligatory grain of salt (*thud*): I haven't finished writing my first page yet. Integrating new stuff into existing elaborate functional test suites takes time.

Almost works out of the box on Ubuntu. Will work out of the box in the forthcoming 9.04 release.

One curious little detail: according to the manual, a blinking green light means it's trying to find the GSM network (if it's blinking twice every 2.7 seconds) or that it's successfully found a GSM network (if it's blinking twice every 2.9 seconds). I'd like to have been on the meeting when this was decided. "I know! Let's make it blink 0.2 seconds faster to indicate it hasn't found a network yet! Brilliant!"

Update: given its shape and position next to my right-hand USB ports, it should double as a USB mouse.

On an unrelated note, Sweden is a very nice country.

I once needed to know about SyntaxError's attributes. Here's what pydoc SyntaxError from Python 2.5 says:

 |  Data descriptors defined here:
 |  
 |  filename
 |      exception filename
 |  
 |  lineno
 |      exception lineno
 |  
 |  message
 |      exception message

So far so good

 |  
 |  msg
 |      exception msg

Hmm?

 |  
 |  offset
 |      exception offset
 |  
 |  print_file_and_line
 |      exception print_file_and_line

Doh!

 |  
 |  text
 |      exception text

My, that was useful. Maybe the online documentation will be better?

exception SyntaxError

...

Instances of this class have attributes filename, lineno, offset and text for easier access to the details. str() of the exception instance returns only the message.

Um. Well, at least now I know I can ignore both 'msg' and 'message'. I think. Still, it would be nice to warn that sometimes the exception text can be multi-line.

If you're developing a web application that runs on Linux, and a customer asks for a report in MS Word format, you're going to be in a lot of pain. One approach is buying a Windows licence, installing it in a virtual machine, and hooking up an application to drive it over COM, and then figuring a way to talk to the VM from your web app. A simpler approach is generating a web archive file (.mht) and pretending it's a .doc file. Word happily opens it, usually.

Here's a random helpful tip: try not to have more than 2047 <ul> elements in it, or they'll start spontaneously nesting.

Does anybody else think it's retarded that volume control keys do not work if you have a menu open in Ubuntu?

I'm sure people can claim there are good technical reasons for that (the toolkit has to grab the X server to implement popup menus, and then gnome-settings-daemon doesn't see the XF86VolumeUp/Down key events or whatever), but if you take a step back and look at this from the user's perspective, it makes no sense.

Yesterday I held a G1 phone in my hands. An interesting little device. I'd buy one in a heartbeat, if I could. T-Mobile sells them only with a data plan, and T-Mobile doesn't operate in Lithuania.

Opennes is the primary reason I'm interested in Android phones. I don't see how that can be compatible with operator lock-in.

Andrew Bennetts writes why narrative tests are lousy unit tests. I completely agree.

Narratives are great as documentation, and the embedded doctest sections help (1) keep the documentation up-to-date and (2) provide concrete examples that make the documentation easier to understand. Here's a good example of that: Storm ORM tutorial. But for unit tests you want many small, isolated tests rather than one big narrative, for reasons that Andrew so clearly elucidated in his post.

My preferred way of writing unit tests is a mixture of unittest and doctest:

import unittest
import doctest
from cStringIO import StringIO

from mysuperduperpackage import Gronkulator


def doctest_Gronkulator_parseXML():
    """Tests that Gronculator.parseXML does the right thing

        >>> g = Gronkulator()

    You pass a file-like object to Gronkulator's parseXML():

        >>> g.parseXML(StringIO('''
        ... <gronk id="g42">
        ...   <item id="a">One</a>
        ...   <item id="b">Two</a>
        ...   <item id="c" important="yes">Three</a>
        ... </gronk>
        ... ''')

    and the items are loaded into ``g.items``:

        >>> for item in g.items:
        ...     print item.id + ':', item.title, '!' if item.important else ''
        a: One
        b: Two
        c: Three !

    """


def doctest_Gronkulator_parseXML_error_handling()
    """..."""


def test_suite():
    return doctest.DocTestSuite(optionflags=doctest.NORMALIZE_WHITESPACE)


if __name__ == '__main__':
    unittest.main(defaultTest='test_suite')

I've written more about this on Zope mailing lists on several occasions.

One of the little things I love about Python is that you can chain comparison operators like this:

10 <= x <= 20

or

x == y == z

Strangely, I hadn't realized until yesterday that this also works with the is operator:

x is y is z

Netspeed is a GNOME panel applet that shows your current upload/download speed in bytes (or bits) per second. I love it. Except... you have to manually say which network device to monitor. If you're switching between wireless and wired, this gets old really quickly. There's an option, Always monitor a connected device, but it is buggy and usually gets stuck monitoring some stupid network interface like wmaster0 or vmnet8.

Today I spent a couple of hours fiddling with netspeed's source code and fixed the bug! Patches attached to the bug report and tested with netspeed-0.14 on Ubuntu Hardy.

While doing this I created a local Bazaar branch for playing with the source code. Sadly, Bazaar decided to hurt me again: bzr viz, instead of letting me look at my commits in a nice GUI window, barfs AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph' and stops. Apparently the latest version of bzr-gtk (trunk from launchpad) is not compatible with the latest version of bzr (1.6rc2 from the Hardy PPA).

It's becoming a pattern: every couple of months I give Bazaar a try, and I hit a new bug that prevents me from doing whatever I wanted to do. Why do I even keep trying?