Stupid Python Ideas

There are a lot of questions on StackOverflow asking "what's the deal with self?"

Many of them are asking a language-design question: Why does Python require explicit self when other languages like C++ and friends (including Java), JavaScript, etc. do not? Guido has answered that question many times, most recently in Why explicit self has to stay.

But some people are asking a more practical question: Coming from a different language (usually Java), they don't know how to use self properly.

Tkinter makes slapping together a simple GUI very easy. But unfortunately, many of its features aren't very well documented. The only way to figure out how to do something is often to figure out what Tk objects it's using, look up the Tcl/Tk documentation for those objects, then try to work out how to access them through the Tkinter layer.

One of the places this most often comes up is validating Entry boxes.

In Python 2.x Tkinter code, you see a lot of stuff like this:

class MyFrame(Frame): def __init__(self, parent, n): Frame.__init__(self, parent) self.n = n Why?

Inheritance and overriding

Some people start on Tkinter before getting far enough into learning Python. You should definitely read the Classes chapter in the Python tutorial, but I'll summarize the basics.

First, you're subclassing (inheriting from) the Tkinter class Frame.

In database apps, you often want to create tables, views, and indices only if they don't already exist, so they do the setup work the first time, but don't blow away all of your data every subsequent time. So SQL has a special "IF NOT EXISTS" clause you can add to the various CREATE statements.

Occasionally, you want to do the same thing in Python. For example, this StackOverflow user likes to re-run the same script over and over in the interactive session (e.g., by hitting F5 in the IDE).

Sometimes you want to write a round-trippable __repr__ method--that is, you want the string representation to be valid Python code that generates an equivalent object to the one you started with.

First, ask yourself whether you really want this. A round-trippable repr is very nice for playing with your objects in an interactive session--but if you're trying to use repr as a serialization format, don't do that.

Many novices notice that, for many types, repr and eval are perfect opposites, and assume that this is a great way to serialize their data:

def save(path, *things): with open(path, 'w') as f: for thing in things: f.write(repr(thing) + '\n') def load(path): with open(path) as f: return [eval(line) for line in f]

If you get lucky, you start running into problems, because some objects don't have a round-trippable repr. If you don't get lucky, you run into the _real_ problems later on.

There are a number of blogs out there that tackle the problems of callbacks for servers, or for Javascript, but novices trying to write Python GUIs shouldn't have to learn about the different issues involved in servers, or a whole different language.

In another post, I showed the two major approaches to writing asynchronous GUI code: threading and callbacks. Both have drawbacks. But there are a number of techniques to get many of the advantages of threads, on top of callbacks.

Imagine a simple Tkinter app.