Lambda at Work

Finally, several years after learning lambda expressions, I got a chance to use one at work a few days ago. As long as I'm putting a notch in my nerd belt, I'd like to write about what lambda is and how it can be useful.

A lambda expression defines an anonymous function. Here's a regular function definition:

def inc(x):
    return x + 1

This definition binds the name inc in the local namespace to a function object. To get the exact same functionality using lambda, assign the lambda expression to a variable:

inc = lambda x: x + 1

A lambda has two parts: the argument list (only one arg in this case) before the: and an expression after. It can't contain statements (like assignments or print) because it's an expression itself. This is a pretty useless example, so let me show how I used it today.

Software Development Book Club

We want your opinion and point of view - and I bet you want to give it to us! So, how would you like to join a book club with your on-line peers?

After last week's post where I mentioned a community workspace I set up at work, Keith and Nola started doing some brainstorming on how we could do something similar with an off-shoot of this site.

Now, we need your ideas on how to set it up and what features it should have, and your opinions on how to make it interesting enough to make you want to participate. There's a common refrain that goes, "I'd love to, but I just don't have enough time." Well, that's only half true because if you really wanted to and looked forward to it, you'd make time to do it. So what would it take to make you look forward to participating?

Last week I read a good quote somewhere about professional development that went something like, 'Where you're at professionally in 5 years will have a lot to do with the quality of books you're reading today.' (if anyone recognizes that quote, post the link to its true source!)

YAPC - NA 2006

Registration is open for the YAPC: NA 2006 being held in Chicago June 26, 27, and 28th. is proud to announce that registration is open for Yet Another Perl Conference North America (YAPC::NA) 2006. The primary conference will occur June 26th through 28th at the Illinois Institute of Technology in Chicago, Illinois. The conference will feature speakers from throughout the Perl community, as well as, keynote addresses from luminaries such as Larry Wall, the creator of Perl, and guest speakers from the broader dynamic languages and open source communities. The full three-day conference costs only $100, but early registrants can take advantage of a 15% discount and attend the conference for only $85. With such a low cost, YAPC is one of the most affordable and accessible technical conferences available today.

In addition to the conference, three open courses will be offered on June 29th and 30th. These courses are taught by some of the most notable Perl instructors: brian d foy, Randal Schwartz, and Damian Conway. The courses will all run simultaneously during the two days after the conference. Conference attendance is not required when signing up for classes, but it is encouraged.

Python Flyweights

I mentioned at the end of my post on Python Equality that another way to solve the example given was to use the flyweight pattern. I gave code for playing cards that would end up with many small duplicate objects in memory, and that memory usage can be reduced if (as in the example) the objects don't have extra state that wasn't used for testing equality.

Let's look at the final version of the Card class and its usage again:

values = ('2', '3', '4', '5', '6', '7', '8', '9', '10', 'J', 'Q', 'K', 'A')
suits = ('h', 'c', 'd', 's')
class Card:
    def __init__(self, value, suit):
        self.value, self.suit = value, suit

    def __repr__(self):
        return "<Card: %s%s>" % (self.value, self.card)

    def __eq__(self, card):
        return self.value == card.value and self.suit == card.suit

    def __ne__(self, card):
       return not self.__eq__(card)

>>> c1 = Card('J', 'h')
>>> c2 = Card('J', 'h')
>>> c1 == c2
>>> id(c1), id(c2)
(-1210559028, -1210558804)

As designed in the previous blog post, two different objects (as seen by their different ids) equate because of the custom __eq__() handler.

But this is a bit silly -- Cards are so small and simple, having identical objects is wasteful. If we're writing the code for a casino, we don't really want several thousand Jacks of Hearts, we want many references to one object. The idea is that instantiating a Card object checks a hidden pool of objects for a duplicate and returns it, creating a new object only if needed. (Code based on that of Duncan Booth.)

import weakref

class Card(object):
    _CardPool = weakref.WeakValueDictionary()

    def __new__(cls, value, suit):
        obj = Card._CardPool.get(value + suit, None)
        if not obj:
            obj = object.__new__(cls)
            Card._CardPool[value + suit] = obj
            obj.value, obj.suit = value, suit

        return obj

Notice that this uses new-style classes. (Side note: I cringe at anything named "new", "next", "updated", etc. because they tell me nothing. If the only thing you can say about a reimplementation is that it's not the old one, put down your copy of Refactoring and back away from the computer. Take up writing toothpaste advertisements.) If you're wondering what's up with __new__, Guido explains the difference best:

__new__ is the first step in instance construction, invoked before __init__. The __new__ method is called with the class as its first argument; its responsibility is to return a new instance of that class. Compare this to __init__: __init__ is called with an instance as its first argument, and it doesn't return anything; its responsibility is to initialize the instance.

The other possibly-unfamiliar element is the WeakValueDictionary. In a nutshell, it's a dictionary that deletes its entries if no other variables point to them. When instantiating a Card object, it checks in the Card class's _CardPool to return an existing object, or creates a new Card object if needed.

If you're confused, take a few minutes to play with the code. Insert print statements into __new__ to show you the contents of _CardPool.items() and whether a new object is created. There's a lot of important object orientation concepts at work in a short block of code: inheritance, the difference between classes and objects, references, and overriding.

I've removed the __eq__ and __ne__ calls because two Cards with the same value and suit are the same objects, saving our casino many gigs of precious RAM:

Micro ISV: From Vision to Reality, Bob Walsh interview on

PerlCast is not just about Perl! Josh McAdams interviews Bob Walsh, author of the book Micro ISV: From Vision to Reality. In it he talks about the definition of a MicroISV, gives advice on starting, marketing and dealing with hostile customers among many other topics.

For a chance to win a copy of the book, see the PerlCast site for instructions on how to enter AND see a transcript of the interview.


If you are not familar with PodCasts, they are simply mp3 files you can play on your PC or any portable device, they are not just for iPods! A transcript is available on the site if you prefer not to listen.

DC PHP Conference - Announcement and Call for Papers

PHP in the Federal Enterprise and the World:  Secure Solutions for Federal Agencies, IT Companies and Non-Profit Organizations

We are hosting the first DC Metropolitan area PHP Conference this October.  Not only that, but since we're in a unique location with opportunities and potential impact like nowhere else in the world, we're taking a slightly different look at PHP. Our mission is to demonstrate and teach how PHP is a solid, sensible, cost-effective, and low risk development language to use for government and non profits.

Therefore, our Presentation Tracks fall into four areas:

  • Integrating PHP with Federal Operations and the Enterprise
  • Security & Accountability
  • The Art of PHP
  • The Business Case for PHP

The Call for Papers ends on July 7th and gives suggested topics in each of these areas.  Your presentation will be up to 400 people including decision makers for some of the largest and most influential organizations in the world.

Ketchup on Rusty

Spring has hit Seattle like a damp blanket. It's better than the 30-days-of-rain from January though, and people are finally getting the moss scraped off their backs. The days are actually light for over 12 hours now, the grass is growing (I've mowed thrice!), and all manner of creatures great and small are crawling and flying.

At the onset of every winter, I say to myself, "This winter I am going to use my gloomy days off and dark week nights to ________," and by this time every year I have done none of it and wonder where the winter went.

One winter a few years ago, I was going to get abs that I could see. That didn't, and still hasn't, happened, although I am in fair shape. Every winter for the past 10 years I've determined that I was going to pass the Microsoft certification exams. I don't even remember why I wanted to do it in the first place, but I've intended to do it for so long now that it is something that just has to get done (I hope that will put it to rest even though MS changes the certification levels every three years).

Equality for Python

A few days ago in #chipy, the chat room for the Chicago Python Users Group, we had a chat about how Python determines equality. It's a pretty neat and extensible technique, so I'm going to walk through how I recently used it for playing cards.

Here's the basic Card class. Note that I'm going to totally skip things like error-checking and documentation to keep the example obvious.

values = ('2', '3', '4', '5', '6', '7', '8', '9', '10', 'J', 'Q', 'K', 'A')
suits = ('h', 'c', 'd', 's')

class Card:
    def __init__(self, value, suit):
        self.value, self.suit = value, suit

    def __repr__(self):
        return "<Card: %s%s>" % (self.value, self.card)

Man, does code get short when you don't bother checking for errors. The usage is pretty clear, but there's one odd issue:

work, work and life balance

I have been quiet here for the last couple weeks, more a reader than a writer. For me one of the more interesting articles of late was Wife of the mISV - Surviving the Business. When I showed it to my own wife, we shared a laugh and a moment of knowing silence - yeah, this one hits home.

Imagine the following. You're working as a software engineer on some pretty deadline-driven projects. You typically have a lot to do during the regular 9 to 5, enough in fact that you've been known to bring some of it home over the weekend, you know, just in case you got some downtime. You have got a significant other and your combined schedules are such that both of you are really always looking forward to the weekends, when you are both available at least most of the time.

Then, an opportunity turns up. One involving work and circumstances that make it very intriguing for you. The only caveat: The way to make it work is to do both jobs together for a while. Your dayjob (telling yourself, not to bring work home anymore on the weekends) and then the new job, on contract-basis in the evenings and weekends. What would you do? And for how long?