In my graph, nodes are represented by Python tuples that refer to the metadata culled from the song list. For example, there is a node for (’Artist’, ‘U2′) and another for (’Genre’, ‘Rock’). I keep track of the relationship between these nodes with a weight that comes from the number of songs that have both of these pieces of metadata.

So for example there is a line between (’Artist’, ‘U2′) and (’Genre’, ‘Rock’) which has a weight of 15, because their new album is categorized as ‘Rock’ – though songs from the album October are categorized as ‘Rock/Pop’

When I combine all the different pieces of metadata in my collection I get a whopping 1589 different facets, represented by nodes in my graph. But whats more interesting is that about 1500 of these nodes are connected, and the other 90 or so are divided into about 30 different individual chunks of 3-4 facets each. I tried to visualize this with GraphViz but the data was just too big.

But this got me thinking more about how to chunk the graph. It was really surprising that so many of the nodes were connected, but really what matters to me is knowing which nodes are the most connected. This means that I could start dropping lines (connections) between nodes where the weight is just 1… or 2, or whatever number yields an appropriately chunked graph. Hopefully that will break up the large cluster of facets into smaller, more usable clusters.

Unfortunately, the interface for PyICU for this kind of thing is a little ugly:

# do some setup, initializing stuff from PyICU
timeFormatter = PyICU.DateFormat.createTimeInstance()
hourFP = PyICU.FieldPosition(PyICU.DateFormat.HOUR1_FIELD)

# Now deal with the current hour
hourdate = datetime.combine(date.today(), time(hour))
timeString = timeFormatter.format(hourdate, hourFP)
(start, end) = (hourFP.getBeginIndex(), hourFP.getEndIndex())
hourString = str(timeString[start:end])

Yuck! The point here is not that PyICU is ugly, but that there is some initialization that must happen before any actual use of the variable ‘hour’

The problem is that I have to do other things with ‘hour’ beyond just getting its time string. So my code would look like:

# initialization...
timeFormatter = PyICU.DateFormat.createTimeInstance()
hourFP = PyICU.FieldPosition(PyICU.DateFormat.HOUR1_FIELD)

for hour in range(1,24):
    hourdate = datetime.combine(date.today(), time(hour))
    timeString = timeFormatter.format(hourdate, hourFP)
    (start, end) = (hourFP.getBeginIndex(), hourFP.getEndIndex())
    hourString = str(timeString[start:end])

Again.. UGLY!

So my first thought was to combine the last 4 lines into a single function, so that I could just say

for hour in range(1,24):
    hourString = GetHourString(hour, ...)

But the problem here is that GetHourString() needs context from the initialization. So it would look something like:

# initialization...
timeFormatter = PyICU.DateFormat.createTimeInstance()
hourFP = PyICU.FieldPosition(PyICU.DateFormat.HOUR1_FIELD)

for hour in range(1,24):
    hourString = GetHourString(hour, timeFormatter, hourFP)

    # do other things with hour and hourString...

What if there were a way to keep the loop simple without the initialization, keep GetHourString() simple without the extra parameters, and still get the benefit of initialization outside the loop.

Enter: Generators

Instead of doing the initialization before the loop, lets hide this all in another function:

def GetLocaleHourStrings(start, end):
    timeFormatter = DateFormat.createTimeInstance()
    hourFP = FieldPosition(DateFormat.HOUR1_FIELD)
    dummyDate = date.today()

    for hour in range(start, end):
        hourdate = datetime.combine(dummyDate, time(hour))
        timeString = timeFormatter.format(hourdate, hourFP)
        (start, end) = (hourFP.getBeginIndex(),hourFP.getEndIndex())
        hourString = str(timeString)[start:end]
        yield hour, hourString

Note that we do some initialization, and then yield the string each time. Nice, but how do we use it?

    for hour,hourString in GetHourStrings(1, 24):

    # do other things with hour and hourString...

Neat, huh?

I needed a way to given a basic color to a class, and then have easy access to various tints of that color for painting different aspects of an object. The tints are based on HSV, not RGB, but all the callers need to deal with RGB.

The solution: wrap the property() descriptor with my own descriptor.

I start by defining my class

class TintedColors(object):
    def __init__(self, color):
        """
        color is an RGB triple
        """
        self.color = color
        self.hue = rgb_to_hsv(*color)[0]

Now I just need to define the property wrapper:

    def tintedColor(saturation, value=1.0):
        def getColor(self):
            hsv = (self.hue, saturation, value)
            return hsv_to_rgb(*hsv)
        return property(getColor)

Finally, I can define all my tints as class attributes:

    gradientLeft = tintedColor(0.4)
    gradientRight = tintedColor(0.2)
    outlineColor = tintedColor(0.5)
    textColor = tintedColor(0.67, 0.6)

What is so amazing about this is that because property is a runtime thing, and because classes are evaluated, not declared, the actual value of “f.gradientLeft” will be a descriptor as generated by property(). Each descriptor will call a special version of getColor() defined for each and every tint. The dynamic nature of this might make it look like it should be slower than a simple property() call, but in fact it is just as fast because the specialized versions of getColor() are very simple, and in memory act as though they were declared as:

def getColor(self):
    hsv = (self.hue, 0.4, 1.0)
    return hsv_to_rgb(*hsv)

which is pretty darn fast.

Lets look at a similar option in C++:

class TintedColors {
private:
    color mColor;
    float mHue;
 
    color GetSaturatedColor(float saturation, float value=1.0) {
        hsv = make_hsv(this.mHue, saturation, value);
        return hsv_to_rgb(hsv);
    }
 

public:
    TintedColors(const color& c) const {
        mColor = c;
        this.mHue = rgb_to_hsv(c).hue
    }
 

    color& GetGradientLeft() const {
        return GetSaturatedColor(0.4);
    }
 
    color& GetOutlineColor() const {
        return GetSaturatedColor(0.2);
    }
 
    color& GetTextColor() const {
        return GetSaturatedColor(0.67, 0.6);
    }
}

There we go. I’ve tried to follow “good C++” guidelines with respect to consts, references, and so forth. And there we have the same pattern in C++ but with way more work: the 4 boilerplate calls meant I had to type GetSaturatedColor() 4 times, and the verbosity allows you to loose what’s really different between these functions – the color saturation and value.

And that’s all assuming that I’ve got a “color” type (which I’d have to define seperately – python just uses the built-in triples for a small value like that) and that hsv_to_rgb is part of that color system.. that may seem like a small assumption. It may not be part of the language, but there are so many extra easy routines just built in to Python that you can’t just write that off.