Archive for the ‘Python’ Category

Nxpy 0.3.0 released

November 30, 2014

I’m happy to announce the availability of release 0.3.0 of my Nxpy library, which is available from PyPI and from SourceForge. Updated documentation may be found here.

The main purpose of this release is Python 3 compatibility: all tests now pass with 3.4, 3.3 and 3.2, as well as 2.7 and 2.6. Parts of the library still work with 2.5. With the exception of the ccase package all tests were run with all Python versions on Windows 7 and Fedora 20, and with all but 2.5 on OS X 10.10. The ccase non-destructive tests were run only on Windows 7 with Python 3.4 and 2.7; the destructive tests weren’t run at all, as I don’t have a test ClearCase installation available anymore.

Given the focus on Python 3 there are almost no new features; a few methods received an additional encoding argument to better support the differences in string handling between 2 and 3.

The only thing that is completely new is the CurrentDirectory class in the path module. This is a context manager that lets you change directory temporarily, a little like the pushd/popd commands.

How I became a Python programmer

August 22, 2013

Read all about it on the Josetteorama blog.

insert_separator

June 25, 2008

I recently realized that there is a problem that has kept cropping up regularly in my code for the last few months: transform a sequence of words in a comma separated list. Not a big issue in itself, but I find it interesting for two reasons: first, it is almost impossible to specify a solution that matches the regularity and simplicity of the expected outcome; second, it’s a good test case for checking how well different languages support writing a generic solution.

I have to confess that I wouldn’t have given it much thought if this wasn’t a kind of problem that really irks my sense of aesthetics; what you want is something as simple as:

string1, string2, string3

A very plain sequence, without any exception or special case. Yet when you try to code it you can’t avoid making a special case of either the first or the last string, as in this Python function:

def insert_separator1(l):
    ret = l[0]
    for s in l[1:]:
        ret += ", "
        ret += s
    return ret

Otherwise you have to insert a conditional inside the loop, which conceptually you should only need to compute once, as in this alternative Python implementation:

def insert_separator2(l):
    ret = ""
    first = True
    for s in l:
        if first:
            first = False
        else:
            ret += ", "
        ret += s
    return ret

By the way, I’m well aware that Python’s standard library provides a ready-made solution:

print ", ".join([ "string1", "string2", "string3" ])

While Python is very convenient to expose programming concepts, the code where this little problem keeps coming up is actually written in C#. This language also has a library solution, which is very similar to Python’s:

using System;

class InsertSeparator1
{
    static void Main(string[] args)
    {
        string[] l = { "string1", "string2",
                "string3" };
        System.Console.Out.WriteLine(
                string.Join( ", ", l));
    }
}

These library solutions are undoubtedly convenient, but they are limited to the scenario where you want to concatenate your list elements into a single string. Sometimes, however, you would rather output your strings to a file, or you might want to interleave other kinds of things, rather than just strings.

Let’s see then how different languages support a generic solution. Thanks to generators and duck typing Python makes it very easy:

import sys

def insert_separator4(elements, sep):
    first = True
    for e in elements:
        if first:
            first = False
        else:
            yield sep
        yield e

if __name__ == "__main__":
    for e in insert_separator4([ "string1",
            "string2", "string3" ], ", "):
        sys.stdout.write(e)
    sys.stdout.write( '\n' )

Slightly less so C#, which is constrained by static typing and the subordination of generics to inheritance as a means of generalization:

class InsertSeparator2
{
    static IEnumerable<ValueType>
            InsertSeparator<ValueType>(
                    IEnumerable<ValueType> elements,
                    ValueType sep)
    {
        bool first = true;
        foreach (ValueType e in elements)
        {
            if (first)
                first = false;
            else
                yield return sep;
            yield return e;
        }
    }

    static void Main(string[] args)
    {
        string[] l = { "string1", "string2",
                "string3" };
        foreach ( string e in
                InsertSeparator<string>(l, ", " ) )
        {
            System.Console.Out.Write(e);
        }
        System.Console.Out.WriteLine();
    }
}

Note that you need to implement the IEnumerable<T> interface in order to exploit this function.

C++ is also statically typed, but thanks to a form of compile time duck typing supported by templates it doesn’t require an abstract base class:

#include <iterator>
#include <iostream>
#include <string>

template <typename InputIter, typename OutputIter, 
        typename ValueType>
void insert_separator(InputIter first, 
        InputIter last, 
        OutputIter out, 
        ValueType sep)
{
    bool initial = true;
    while ( first != last )
    {
        if ( initial )
            initial = false;
        else
            *out++ = sep;
        *out++ = *first++;
    }
}

int main()
{
    std::string l[] = { "string1", "string2",
            "string3" };
    insert_separator(l, l + 3, 
            std::ostream_iterator<std::string>(
                    std::cout), 
            ", ");
}

At first sight the C++ solution isn’t much better than the C# one. However generalization is not just a matter of language constructs; it is also a matter of conceptual framework. With little effort from our part the function above integrates perfectly with the standard library’s iterators and containers, as well as with any user defined ones, provided they adhere to the standard library constraints.

Finally, there is a solution to this problem which satisfies my quest for elegance, but it’s currently late at night and this post is already long enough as it is 😉

Talking ’bout Code Generation

May 5, 2008

In a perfect display of self-promotion, I forgot to announce here that I had a presentation proposal accepted for the ACCU Conference 2008. To get an idea of what I talked about you can read the proposal and browse through my slides.

Basically I expressed the view that code generators are a very effective means of dealing with the kind of repetitive tasks that tend to crop up when programming, especially if you use effective tools such as Python as programming language, a parser generator such as PLY for information acquisition and a templating engine such as Cheetah for the actual generation.