No official talks were scheduled so we resorted to the old standby of asking for lightning talks. Lightning talk nights are great because there's always a wide variety of content. The group gets so engage in the topic and inline discussions that the talks will last for upwards of 20 minutes instead of the standard 5. That's an observation not a complaint.

Eric Faehnrich teed up some great discussions with a closure talk. The coolest thing I learned during the talk was that Eric learned Python so that he could experiment with closures. Very awesome!

Jeff Armstrong gave us a preview of his upcoming PyOhio 2011 talk. He got Python working on the FreeMiNT operating system which is a UNIX-like environment for ancient Atari hardware. It got me thinking about hacking CPython again...we'll see if time permits...

Beyond those two great talks we talked about a wide range of topics. I talked about my use of closures in snake-guice. Mike Nugent drove some conversation with his Django questions. On the way out Dale Smith was explaining the Emacs operating sys^H^H^H editor. He may be talking about it next month.

Summary: looking forward to the next meeting.

This morning I attended a very inspiring talk by Jim Weirich where he talked about the correct way to do unit testing. Someone (aka Skeptic) asked an interesting question during the Q & A and unfortunately it wasn't really answered. The lack of time and detail made it difficult for Jim to answer and he punted. I'm going to attempt to answer the question as I understand it (or as I want it to be).

If I understand the question correctly Skeptic was asking how to test an algorithm. His example was a system where forms were generated dynamically based on prior input. For example, if a user checked a checkbox on formA then formB contained a few extra fields. When submitting a form the system must be able to handle dealing with knowing what fields are there/not there. The concern was that there are so many combinations of forms and fields that testing each one would not be worth it.

I agree! So what would you do? Step back and think about the fundamental problem. Skeptic really wanted to test the fact that the system can deal with a missing field. It really doesn't matter that there are 5 possible combinations of fields or 50,000. If the algorithm for validating the missing field handling is correct you are likely in a good position.

Unit test the algorithm and not the entire dataset. Take a look at the prime factors kata for a really simple example of what I'm talking about.

PyOhio is an annual conference for Python programmers in and around Ohio. PyOhio 2010, the third annual conference, will take place July 31 - August 1, 2010 at Ohio State University's Ohio Union.

1. Download Gnome Gmail
2. Install it! I used the .deb because I run Ubuntu.
3. Go to System -> Preferences -> Preferred Applications
4. Select Gmail in the Mail Reader drop down

• I added a --cover-branches option to make coverage.py generate branch coverage statistics.
• I changed the existing --cover-html option to use coverage.py's built-in HTML report generator. Why have old, outdated logic hanging around?

class SubClass(BaseClass):

    def method(self, arg, this=that):
        super(SubClass, self).method(arg, this)

To avoid doing an real work I hacked together an alternative implementation. I was able to get something that appears to work correctly, but I can't guarantee it. With my new super the code would look like:

from better_super import super

class SubClass(BaseClass):

    def method(self, arg, this=that):
        super().method(arg, this)

This should not be used in any real production code. There are likely bugs lurking in corner cases and strange failure modes. It's also four times slower than the built-in super.

It was still interesting to explore the implementation and I learned a bit about frames in the process.

My hacky implementation:

# better_super.py
import inspect as _inspect
from __builtin__ import super as _builtin_super


def _what_class_am_i_in(mro, func_name, func_code):
    for c in mro:
        if getattr(c, func_name).func_code is func_code:
            return c
    return None


def super():
    frame = _inspect.currentframe().f_back
    arg_info = _inspect.getargvalues(frame)
    self = arg_info[3][arg_info[0][0]]
    mro = _inspect.getmro(self.\__class__)
    method_name = frame.f_code.co_name
    code_obj = frame.f_code
    cls = _what_class_am_i_in(mro, method_name, code_obj)
    return _builtin_super(cls, self)

I'd love to hear about other ways to implement this. Have you tried yet?