Thanks for fixing the formatting. Looks like the tags in the string quotations got nixed by my not escaping the code blocks too. As it stands, the code doesn’t quite conform to specification

– Lwe

There’s a light on the front of the laptop that indicates Wireless status — but it’s a button as well as a light, and not very obvious.

out4 lst =
    let 
        processSplitSequence leading trailing = 
            (map fromChar leading) ++ (if isEmpty trailing then [] else ([""] ++ (map fromChar trailing) ++ [""]));
    in
        unwords $ concatMap (uncurry processSplitSequence) (map (splitAt 2) (group lst));

This does the same as out3, except that spaces are rendered between the tags and the span sequence. This approach has the overt concept that sequences are composed of leading elements (the 2 items rendered ahead of the tagged block), and trailing elements (the remainder of any sequence).

Again, ‘group’ really does most of the heavy-lifting. After that, we simply split groups into leading and trailing sequences, then project each of these sequence pairs as the appropriate list of strings. Then we concatenate the renderings from each group. Finally, we use ‘unwords’ a library function that renders a list of strings as a single string with space separated elements.

For the uninitiated, the weird ‘uncurry’ is only there because I chose to define processSplitSequence as a function of two clearly named arguments. This has to be applied to a single pair (2-tuple), which is what uncurry does here. An alternative could be:

out4a lst =
    let 
        processSplitSequence seqPair = 
            (map fromChar seqPair.#1) ++ (if isEmpty seqPair.#2 then [] else ([""] ++ (map fromChar seqPair.#2) ++ [""]));
    in
        unwords $ concatMap processSplitSequence (map (splitAt 2) (group lst));

…though it would be good in this case to create a let definition in processSplitSequence to capture “seqPair.#2″ once.

• Use Pydev plugin for Eclipse and configure Pydev to use Pylint
• Write lots and lots of unit tests

The first of these catches most of my typos right there as I make them (and a lot of other errors too), and also provides a pretty good code completion support. I’ve never relied on code completion with any language, so I don’t actually see 100% support as a big deal.

The second point is good regardless of the programming language, but due to Python’s nature I feel unit tests can cover some of the things you’d otherwise expect a compiler to do. And because Python makes it really easy to create and run unit tests it is a win-win in my opinion.