Posts Tagged Python

Making Python’s sqlite3 import easy as 1 2 3

Lurking within the normal Python 2.x distribution is the sqlite3 import, which is an amazingly powerful, no-server-required, mostly SQL compatible database engine that can be used in any project without restriction.

That’s the up side. The down side is, as a fairly complete database, there are many options and varied ways it can be used, and managing actual database transactions isn’t all that simple — to do it right, even a single query takes about sixteen lines of code. And yes, if you want maximum flexibility and the ability to use every feature in sqlite3, that’s how you should do it.

But. Most database operations are very straightforward. You want to issue a single command to the database, or a query. Perhaps you want to write a bunch of data and then commit it all at once so that the database doesn’t contain part of the data from a more complex transaction. You need to know if something went wrong, and if it did, what it was. Those are by far the most common use cases for me, and I suspect that’s true for others as well.

Frankly, it’s difficult enough dealing with the SQL query language itself. Why make actually using it harder than it has to be?
Read the rest of this entry »

Tags: , , , , , , , , , , , , , ,

What’s that Smell?

As they train to become a doctor, new interns are taught about many different diseases that produce various sets of otherwise similar symptoms. In conjunction with this new and complex knowledge, they are also taught this truism: “When you hear hoofprints, you must not initially assume a zebra is in the vicinity.” This pithy remark is meant to impart that, for instance, if a patient comes in bleeding from an orifice, one must not immediately assume that Ebola is in the building; more likely something much more common is in play, such as hemorrhoids or perhaps an unfortunate excess of enthusiasm coupled with a new, ahem, toy.

One of the clearer signs that I was becoming a competent programmer was that the problems in my code began, more and more often, to in fact, be zebras. Instead of a misplaced character or a missing clause or some kind of blatant conceptual error, the abject weirdnesses that were most often populating the realm of my final, demonstrably accurate diagnoses came to be things like operating system bugs, broken libraries, incomplete emulations and exotic compiler bugs. Zebras.
Read the rest of this entry »

Tags: , , , , , , , ,

Catching ALL exceptions in Python

When working with Python, sometimes, more than anything else, you need to know what went wrong. Quite aside from all the debate about what you should do in response, and particularly when developing, you need more than just a vague idea that your CGI bailed and that there might (or might not) be some usable indication of this in the system web logs.

Even when working in a pure command line context, you may need to catch anything and everything. If you do, the following gives you a basic model of just how to do it.

import sys try: a = 5 / 0 except Exception,e: # the Exception class provides messages print 'Exception caught, message: '+str(e) raise SystemExit # bail out (optional) except: # other exceptions e = sys.exc_info() # so we mine sys library info instead print 'Non-Exception class Exception caught, message: '+str(e) raise SystemExit # bail out (optional) else: # and, well, sometimes things work out. print 'it worked, no exception!' # whoo hoo... finally: # always happens print 'Glad THAT ordeal is over -- one way or another.' print 'And here we are. Aren't we?' # you only get here if things worked out

Try out the above with code you know will work, like a=1 immediately subordinate to the try: clause, and then with code you know won’t work, like a=5/0 and see what it does.

Something to keep in mind: The ELSE clause of a TRY block only runs if execution proceeds off the end of the TRY section. So if you have two statements in the TRY section, and the first one runs but the second one does not, the ELSE clause will not execute. The EXCEPT clause will due to the exception. FINALLY always, always runs, even if the EXCEPT clause has an exit in it.

You can think of the ELSE as being functionally equivalent to just putting code right after the TRY-EXCEPT-ELSE-FINALLY sequence if you build an unavoidable exit into the EXCEPT portion. Of course, it’s nice to put related code in, because that makes the functionality and intent more obvious. And if you don’t have an exit there… then ELSE can be quite useful, as it won’t run if the TRY block fails, but the code after the entire TRY-EXCEPT-ELSE-FINALLY sequence will.

Hope someone finds this useful. Took me a while to dig through it all and wrap my head around even the basic idea that sometimes, you just need to know!

Tags: , , , , ,

Python, TkInter, OSX (OS X) and making it all behave

I use Python a lot. Python 2.5.1 to be specific. And inside Python is TkInter, which, with a little work, will give you a handy way to put a GUI together. But there are problems. To say that TkInter is poorly supported and poorly documented under OSX is to understate the case rather dramatically. So you’re left to Google for answers, and mostly, they aren’t to be found — or if they are, they aren’t obvious or easily found. So I’m going to provide some answers here that have taken me quite some time to collect, and hopefully keyword and title them so that a Google search will actually get you to the solution you need sooner rather than as much later as it did me!
Read the rest of this entry »

Tags: , , , , , , , , , , , , , , , , , , , ,

Interp project

graphYeah, about that coding problem. More of the same. This one is about generating temperature and humidity estimates with a single latitude / longitude input using the point measurements of the National Weather Service nearest the point of interest, and interpolating in a useful and hopefully likely manner. As a project, it gets its own static page, right here.

Tags: , , , , , ,

PD database

I’ve written a public domain (that means there are no restrictions on how you use it) database engine in Python. It is very small, about 20k, and it is a single class that will run without adding any other software, module, or technology.

There are presently two versions. The original handles ASCII and integer fields; the newest version, which I presently consider to be beta in that it has not been extensively tested, adds the ability to handle binary, extended character sets, and floating point numbers.

If this is of interest to you, you may learn more about it, and/or download it, on this page.

Tags: , , , , ,