tail -f findings.out

Python’s introspection abilities are quite extensive and useful. They are also well-documented, so I won’t go into the basics here. Check out this article if you need a good overview. N.B.: discussion and code below applies to both methods and attributes. I will simply refer to “methods” for simplicity.

Beyond simply listing the methods of an object, however, I often find that I want to search through them for something in particular. And eyeballing the output of dir(obj) is only efficient in the simplest of cases. hasattr(obj, “method”) won’t get you far either, as you need to match the “method” name exactly. What if you just have a good guess about the name of a method based on what you need to do? What if you want to know everything you can do with directories in the os module or ISO related methods in datetime.date? I haven’t found anything to help with this sort of problem yet. Approaches like writing a loop to do the search every time or perusing the pertinent API docs are too circuitous for such quick questions. So let’s make a tool to do this more easily!

We start with knowing some object and some string containing all or part of the method(s) we’re interested in:

This simply iterates over the methods and attributes defined for the object passed and looks for the term passed within the name of each. rfind returns the highest index of the substring passed in the string it’s called on and returns -1 if no match is found. Once the matches are collected they are printed out. An example:

For convenience let’s make it available on the Python interactive prompt at every load without any extra effort. This is easy enough using a .pythonstartup file. This file can be used to load various useful items like tab completion for interactive Python sessions. If you haven’t used it before, you’ll need to add the following to your .bashrc:

Then in your home directory create a .pythonstartup file containing something like the following:

You’ll need to change the path specified to wherever you placed utils.py containing the mf() function of course. You can download mine here if you’d like. The del statements are to clean up any trace of this operation once you get to the interactive interpreter. This way you get the added functions without mucking up your namespace.

This also loads in an obinfo(obj) function that I included in the same utils.py file. This is based on the interrogate() function written by Patrick O’Brien in the introspection article mentioned above. My version just adds a check for objects without docstrings and prints more of the docstring:

It’s fairly useful:

The MySQLdb Python module implements the Python DB API for MySQL. I’ve written about its use before. MySQL issues warning messages in a number of circumstances and PEP 249 (which specifies the Python DB API) describes a Warning error message to be included.

One issue I ran into recently was how to catch warnings thrown by this module when running queries. Oftentimes tutorials or forum discussions that cover warnings in the context of MySQLdb describe how to filter them (they can clog up script output). But in a recent case I wanted to grab and check the warning, logging a dependent result. I had hoped this clean implementation would work in a method used for all calls to the MySQL DB:

But the warnings just went right through. Instead I needed the warnings module’s assistance:

This catches the warnings and raises them as errors, although their class is still correct, allowing a clean implementation to call the above code (wrapped into a method called do_query):

optparse is a flexible and powerful module for processing command line options in Python programs. I’ve used it for a while, but I didn’t have much occasion to get into callbacks until recently. A callback here is a user-defined function optparse calls when its associated option is encountered. They can help you keep your script’s logic clear within a forest of options by providing arbitrary checks when particular options are passed.

When I first began using them, I ran into a critical point of confusion that wasn’t clearly illuminated in the assorted guides I found for optparse. In response, here is a short overview of how to use callbacks to perform checks and validations against passed options.

First, a very basic script using optparse for option parsing:

Which outputs:

For a more detailed coverage of the basics, review Doug Hellman’s PyMOTW article on optparse. It would be best to verify that this input file exists so that we might inform the user and exit early. Adding that functionality to our example:

We’ve added a check_file() function to perform our check and also added the callback specification to the associated option. The arguments a callback function is passed are described in the module documentation. optparse.OptionValueError provides an elegant way to send an error message about the problem and quit the program in one step.

So what’s the problem? When I first wrote a callback, I didn’t catch the line in the tutorial examples that set the value of the option. I still don’t understand why this is necessary, but without the “parser.values.inputfile = value” line above, you’d find the inputfile variable to have None for its value. Strange, but true. I could understand the callback function having to return the option value if all was well, but why would the option’s value get unset in the first place?

Additionally, it turns out you have to set the option’s type even if the desired value is supposed to be default. In the above example, without ‘type=”string”‘, the callback function would have thrown an error, complaining that we were claiming to use a string and weren’t.

So watch out for these details, and clean up your scripts with callbacks.

On several occasions recently I found did not know what event to specify to trigger something in my wxPython apps. I had a hard time finding anything close to a comprehensive list of all events available, so I was limited to posting questions on the wxPython users mailing list. And, while this is a wonderful and active list, it would be nice to have a guide even closer at hand.

Cody Precord on the list provided me with a handy way to get this:

Run that, and out comes a list of all the EVT types. Of course, in some cases you may not know what the event is just from the name, but they are mostly self-explanatory. See for yourself: