Curia

While writing scripts, I frequently run into the issue of needing to re-arrange sets of data into a more “process friendly” format. A common issue I encounter is needing to turn a list (array) into a dictionary (associative array) or vice versa. More often than not, I find myself needing to be able to access list elements by a key, but since they aren’t setup in a dictionary I have to pull out a looping technique to reorganize the data for this to be possible.

Take the following set of data for example:

[[1, 'John Smith', 'admin'],
 [2, 'Jane Doe', 'superuser'],
 [3, 'Sam Jones', 'user']]

What we have here is a few rows of user data. In this example, the data is in a Python list (which in PHP would be an array).

In PHP, this would look something like (using print_r):

Array (
    [0] => Array (
        [0] => 1
        [1] => John Smith
        [2] => admin
    )
    [1] => Array (
        [0] => 2
        [1] => Jane Doe
# (...etc...)

So, what if I found myself writing some code that needed to be able to access each record by its first value, which in this case would be the user_id? (continue reading…)

I recently had to setup a special marketing web-portal for a client of mine that would collect some basic information and throw it into a database to be retrieved later. Since I’ve already got most of the client’s web-stuff on TG2 (and in an effort to keep things DRY), I decided I’d just add a controller for the new pages to TG and use some mod_proxy kung-fu to make it look like it all lived autonomously. Easy enough, right?

Well, about halfway through this process I decided I wanted to have the collected information dump into its own SQLite DB, keeping it safely away from the rest of my client’s data. I had heard that setting up multiple databases in TG2 was supposed to be easy, and with some help from Google I soon ran across this thread on the ML. In it, Chris supplies some very helpful example code which Mike subsequently posted on his blog as a nice tutorial. However, neither of these resources were exhaustive enough to achieve what I was looking for without a bit of “stumbling around”, so in an effort to be overly verbose (and perhaps unnecessarily repetitive) I’ve decided to post what I hope will be a more comprehensive run-down of how to accomplish this task.

Disclaimer: I am in no way a TurboGears or SQLAlchemy expert. There’s probably an easier/better way to do this, but since there’s no “official” TurboGears tutorial on this topic yet I’m afraid this is the best method I’ve found so far. If anyone reading this knows a better way to implement this kind of thing, please leave a comment and I will update this post as the suggestions come in.

Step 1: Define your database urls in the [app:main] section of your .ini file(s)

This is where the magic begins. Instead of one simple sqlalchemy.url = assignment, you’ve got to create assignments for each of the databases you want to use: (continue reading…)

In a previous post, I briefly mentioned falling in love with Python. Now that I’m finally using Python for a large percentage of my development and am more than “casually acquainted” with its toolset, I thought it would be fun to highlight a few reasons why Python has become my new language of choice.

In an effort to help you understand where I’m coming from, let me (briefly) rehash some of my programming history: I spent much of the 90′s doing dynamic web development using Perl (weren’t those the days!). I eventually migrated to PHP which usually made things much easier on the web; and subsequently replaced most of my console scripting with BASH [shell scripting]. However, I’m kind of a hack and love languages so I have occasionally been known to write something in C; and although I’m not a complete stranger to Java and Ruby, I never really felt like I “clicked” with either of those languages.

Ok, now that I’ve hopefully convinced you that I’m not just a fly-by-night programmer, let me show you some Python code. Brace yourself, as this article is bound to get lengthy… (continue reading…)