package main

func main(){
takesAFunction(foo);
var f Stringy = returnsAFunction();
f();
var baz Stringy = func()string{
return "anonymous stringy\n"
};
fmt.Printf(baz());
}


This compiled and ran, giving the right output, so it looks to me like functional programming is indeed possible in Go, and on the Effective Go page we learn, “In Go, function literals are closures: the implementation makes sure the variables referred to by the function survive as long as they are active.” So that’s kind of cool.

Go also has rich, high-level concurrency support similar to Erlang, several features that prevent random memory from being read or written, and both strings and maps (dictionaries, hash tables) are built-in datatypes. It has a small, but powerful standard library.

One puzzle down, several to go. I still want to explore how I can talk to Cocoa from Go (for GUIs), how to wrap libraries such as libxml2 and cairo for Go, and basically how to map more Python/Javascript library goodness into Go’s world.

I have smaller questions too: can I add methods to existing types? How do I load the contents of a URL? It’s looking good so far! Tune in next time for more exploration.

Briefly, AOP is about separating out Aspects which are are interspersed throughout your code (in AOP lingo, cross-cutting). The canonical example is logging, but there are others.

For Python, as long as you’re content with before/after aspects, the situation is good. In Python 2.5 and up there are two main tactics: decorators and context managers. Decorators use the @ syntax and context managers are used with the “with” keyword.

Decorators

Decorators are only usable on functions and methods in 2.4 and 2.5, but in 2.6, 3.0 and beyond they can be used on classes as well. Essentially they are callables (functions, methods, objects) that accept a function object and return a function object. They are called when the function is defined, so they get a chance to have their way with it: annotate it, replace it, or wrap it. The common case is to wrap it.

Quick example:

import logging
def before(fn):
    def wrapped(*args, **kws):
        logging.warn('about to call function %s' % fn.func_name)
        return fn(*args, **kws)
    return wrapped

def after(fn):
    def wrapped(*args, **kws):
        retVal = fn(*args, **kws)
        logging.warn('just returned from function %s' % fn.func_name)
        return retVal
    return wrapped

OK, those are three basic wrappers, you can use them like so:

@before
def foo():
    logging.warn('inside foo')

@after
def bar():
    logging.warn('inside bar')

@before
@after
def baz():
    logging.warn('inside baz')

foo()
bar()
baz()

This will result in the following output:

WARNING:root:about to call function foo
WARNING:root:inside foo
WARNING:root:inside bar
WARNING:root:just returned from function bar
WARNING:root:about to call function wrapped
WARNING:root:inside baz
WARNING:root:just returned from function baz

You will note that when we use two decorators on baz, the name of the function called by before is “wrapped.” This is because what before is called on is the result of after. The functools.update_wrapper function is useful in this case to make a wrapped function look more like the original function.

For more, please see PEP 318 Decorators for Functions and Methods: Examples and PEP 3129 Class Decorators. For convenience when creating new decorators, see the standard library functions functools.update_wrapper and functools.wraps.

Context Managers

Context Managers are used with the with statement, and are handy for resource aquisition and release. In Python 2.5 you have to “from __future__ import with_statement” to use them, but they are built-in in Python versions later than that. Also, objects such as files and locks are context managers now, so you can use patterns like

with open('example.txt') as example:
    for line in example:
        do_something(line)

This will automatically close the file when leaving the with block. And for locks the pattern is similar:

with myThreadingLock:
    do_something_threadsafely()

It is important to note that the lock will be release properly, or the file closed, even if an exception is thrown inside the with block.

If you want to create your own context managers, you can add two methods to your objects: __enter__(self) and __exit__(self, exception_type, exception_value, traceback). The return value from __enter__ will be passed to the optional as variable (seen in the file example). The __exit__ method will be called with exception info if there was an exception. If no exception is raised in the with block, then all three arguements will be None. If __exit__ returns True then any exception will be “swallowed”, otherwise the exception will be re-raised after any cleanup.

For more info, see PEP 343 The “with” Statement, especially the examples section, and also the helper functions in the standard library contextlib.

AOP and 80/20

Full-on aspect-oriented programming is beyond the scope of this post and involves join-points, code weaving, and other such arcanery. There are multiple Python libraries which target aspect-oriented coding styles, but for my money, the simplicity of the methods in the standard library, coupled with my impression that they cover at least 80% of the uses of AOP, make me favour these built-in techniques over any of the special purpose tools.

Well, my Balding for Dollars event was a success. I have raised $717.37 for Children’s Hospital (there is still time to help bring it to my goal of $1000 if you’d like to donate). Thanks to everyone who helped with donations, words of support, and especially to Frank for his photography, to Berenice for helping with the cutting, to my wife Daniela for her encouragement and help, and to our kids for their patience. I couldn’t have done it without all of you.

There has been one change of plans. I had wanted to donate the hair to a Canadian foundation making wigs for kids with cancer, but couldn’t find it. Daniela’s google-fu skills were better and tomorrow my hair will go off to the Eva and Co. hair donation program. And to clarify, my daughter didn’t shave her head, we’re sending a ponytail from when she went from a long hairstyle to a short one.

Thanks also, to everyone who offered me a toque, but I’m well covered.

I usually use this site to try to give back to the community, with Python and Javascript tutorials, software, and the occasional joke. Today I’m going to ask for something in return. On Saturday, February 14th, 2009 (Valentine’s Day, at least in the US and Canada) I will be shaving my head to raise money for Vancouver Children’s Hospital as part of their Balding for Dollars drive.

The picture above was taken today by my friend Frank Lee. As you can see, my hair is quite long. I’ll be sending my ponytail to Locks of Love, who make a wigs for kids who have lost their hair due to medical conditions. This is my second balding for dollars and will be the fourth ponytail I’ve donated, and my daughter is also donating her ponytail. As I get older, my hair isn’t growing in like it used to. This may be my last good ponytail to give, so with your help, I’d like to make a difference.

You can make donations on the Balding for Dollars site here. Saturday is only two days away, so be my valentine and help some kids!

I appreciate any help you can give. Check back on Monday for before/after photos. Thank you!

Anyway, here are some examples showing how to draw polygons with variable opacity (or alpha). I’ve got examples for NodeBox, aggdraw, and pycairo. I was going to do some for the browser canvas, Processing, PyObjC, and SVG, but a) I wanted to get this post out, and b) PyCairo can already output to SVG and Cocoa (and Processing will be very similar to NodeBox). So if there is any interest in those examples, or others I may have forgotten, let me know in the comments.

While the images below look identical (at least they do to me), each was drawn with its respective library.

For each library I will present the drawing function and the main function that sets things up and drives it. At the end I will present the utility functions used which were the same for all libraries. No optimizations here, just the simplest thing I could do that worked.

NodeBox

I began with NodeBox, because it is so easy work with. In Processing they call programs “sketches” and in NodeBox that is very much what it feels like. The first thing I worked up was a way to draw “random” polygons in the same way for each libary. I could seed the random with a set value, but decided to use random to generate starting values, then just re-use those initial values. To get 50 different polygons, I used a list of primes, chose from the list at random, then used those selected values to increment each polygon vertex and color value (red, green, blue, and alpha). All of which was probably more work than was strictly necessary, but should be stable across different versions of Python and different operating systems.

The drawing routines all have the same signature. They take a tuple of point tuples (x,y) and a tuple of colors (r,g,b,a) as ints between 0 and 255.

def nodebox_poly(pts, clr):
    fill(*ints2floats(clr)) # convert ints in range 0-255 into floats between 0.0 and 1.0
    beginpath()             # every time we want to change colours or linewidth we need to start a new path
    moveto(*pts[-1])     # start and end at the last point in the list
    for pt in pts:
        lineto(*pt)
    endpath()

def nodebox_main():
    size(WIDTH, HEIGHT) # nodebox wants to know how big a canvas you are working with
    draw_all(nodebox_poly) # No additional setup needed

PyCairo

The lines in cairo_main where we create the surface and where we save it are all we would have to change if we wanted to generate a Cocoa view, an SVG document, a PDF document, etc. Two of the main differences between this and the NodeBox example are that there is a bit more setup (Cairo doesn’t default to a white background) and we need to have a reference to the context for drawing, where NodeBox has an implicit drawing context.

def cairo_poly(pts, clr):
    ctx.set_source_rgba(*ints2floats(clr))
    ctx.move_to(*pts[-1])
    for pt in pts:
        ctx.line_to(*pt)
    ctx.close_path()
    ctx.fill()

def cairo_main():
    # Setup Cairo
    import cairo
    global ctx
    surface = cairo.ImageSurface(cairo.FORMAT_ARGB32, WIDTH, HEIGHT)
    ctx = cairo.Context(surface)
    # fill background white
    cairo_poly(((0,0),(WIDTH,0),(WIDTH,HEIGHT),(0,HEIGHT)),(255,255,255,255))
    draw_all(cairo_poly)
    surface.write_to_png('cairo_example.png')

aggdraw

The aggdraw example is very similar to Cairo. In fact, if I’d done either of these first, I would have passed the context object around and simply ignored it in NodeBox to eliminate a global variable. Aggdraw can draw in memory without using PIL, but doesn’t appear to have a way to write to a PNG image that way, so we draw to a PIL image (which requires us to flush all drawing operations before writing the file).

def aggdraw_poly(pts, clr):
    import aggdraw
    global ctx
    b = aggdraw.Brush(clr, clr[-1])
    pts2 = []
    for p in pts:
        pts2.extend(p)
    ctx.polygon(pts2, b)

def aggdraw_main():
    import aggdraw, Image
    global ctx
    img = Image.new('RGBA', (WIDTH, HEIGHT), "white")
    ctx = aggdraw.Draw(img)
    draw_all(aggdraw_poly)
    ctx.flush()
    img.save('aggdraw_example.png')

Utilites

These were the same for all of the examples. If you put it all in one file (or use mine, linked below) you can choose what library to use by switching which main function is called.

MIN_ALPHA = 50
MAX_ALPHA = 100

WIDTH = 500
HEIGHT = 250

#
#   Utilities
#
def hex2tuple(hex_color):
    return tuple([int(hex_color[i:i+2], 16) for i in range(1,9,2)])

def tuple2hex(tuple_color):
    return "#%0.2X%0.2X%0.2X%0.2X" % tuple_color

def ints2floats(tuple_color):
    return tuple([c / 255.0 for c in tuple_color])

def inc_point(p, dp):
    return (p[0] + dp[0]) % WIDTH, (p[1] + dp[1]) % HEIGHT

def inc_triangle(t, dt):
    return tuple([inc_point(t[i], dt[i]) for i in range(3)])

def inc_color(c, dc):
    new_c = [(c[i] + dc[i]) % 256 for i in range(3)]
    new_a = (c[3] + dc[3]) % MAX_ALPHA
    if new_a < MIN_ALPHA: new_a += MIN_ALPHA
    new_c.append(new_a)
    return tuple(new_c)

def draw_all(draw_fn):
    triangle = start_t
    color = start_c
    for i in range(50):
        triangle = inc_triangle(triangle, dt)
        color = inc_color(color, dc)
        draw_fn(triangle, color)

#
#   Starting and incrementing values
#
start_c = hex2tuple('#0xE6A20644')
start_t = (127, 132), (341, 171), (434, 125)
dt = (107, 23), (47, 73), (13, 97)
dc = 61, 113, 109, 41

As you can see, these libraries are all quite capable of producing nice vector-based, anti-aliased polygons with alpha blending. I have heard anecdotal evidence that AGG is faster than Cairo, but Cairo appears to be more widely used. Aside from that I don't know why one would be preferred over the other (unless you want to get into language wars: AGG is written in C++, Cairo is written in C). Both have bindings in a number of languages besides Python, if that's your thing. NodeBox is still my favourite tool for noodling around in with graphics programming. All of these are great fun, easy to use, and handy to have in your bag of tricks.

I tested this under OS X (required for NodeBox), using pycairo installed via fink (using fink's Python 2.5) and aggdraw installed via easy_install (using the builtin in Python 2.5).

Here is my test file containing all of the code above: Alpha polygons example code