Now, this guy hasn’t exactly been living under a rock for the past 10 years—his resume was quite impressive and included projects in a number of different programming languages; But as you can imagine, I was rather surprised by his response, and it made me wonder: Has the Python community really been that bad at promoting the strengths of Python for web development? Or, does the nirvana experienced by switching from a language like PHP to Python just make us so at peace with the world that we forget the hordes of developers still stuck with C-style syntax? Either way, it got me thinking about a few of the reasons why I decided to switch from PHP to Python; and why I not only see Python as an excellent PHP replacement, but am surprised it is such a “best-kept secret” for web development.

There are already plenty of pages out there discussing Python vs. PHP as a language, so I probably won’t get too technical here. I also want to try avoid turning this into a “Python is better than PHP because…” rant (for more on that, please see the end of this post), so I will simply share with you a few of the main reasons why I decided to replace PHP with Python as my primary language for web development:

» Python is more flexible than PHP

Python was engineered from the beginning to be a general purpose programming language. PHP on the other hand was written to overcome many of the “limitations” of the cgi-bin. This should say a lot about the “soul” of each language, but the conclusion I have come to is:

• PHP is meant to do web things really well
• Python is meant to do most things really well

Sure, these days you could write a desktop GUI in PHP, but it would most likely not be the right tool for the job (and you’d probably get laughed at). On a somewhat related note: many PHP developers I know find themselves switching between PHP for their website tasks, and a variety of other languages for other tasks (Shell Scripting for command-line scripts, Perl for text processing, etc.). As a Python programmer, I can typically stick to one programming language no matter what the task at hand requires (especially when armed with iPython).

Now, the obvious argument for PHP at this point is: “But wait, since PHP was written specifically for the web, shouldn’t that actually give it more credibility as the right tool for the web job?” Well, 5 or 10 years ago I might have agreed with you, but web development has changed a lot in the past few years (not to mention the introduction of Python’s WSGI spec).

The internet as a platform has grown and mutated drastically and now requires much more than “a server-side extension to HTML.” We are now in an age of full-blown internet applications, which require a true “application-level” language. In my opinion, PHP has only recently begun to move in that direction with the v5.3 release (as well as updates expected in PHP 6). That alone should give you pause when pondering PHP’s ability to “keep up” with the growth of the web.

In short, the internet continues to transform into an arena that is much less of a website platform, and much more of an application platform. To me, this makes a general purpose language such as Python the obvious choice for “future-proof” internet development.

» Python is typically faster than PHP, even especially on the web

You might find PHP beating out Python in a simple “hello world”-type test, but “real-world” applications will typically run much faster in Python. In a Web 2.0 world where everyone has broadband, speed is now an important factor in keeping your visitors happy.

In addition to “raw, under-the-hood” speed, Python’s language philosophy means it will typically scale better than PHP (although this can be argued a million different ways, since scalability usually involves much more than the language).

I’ve already done benchmarks comparing a few popular web frameworks, but if you’re still curious I’d suggest you dig around with Google for a while.

» Python is easier to read and maintain than PHP

Any veteran programmer will tell you that code readability plays a huge factor in code maintainability. With that in mind, Python was designed with some pretty strict syntax rules in regards to code-blocks and whitespace. While this may initially frustrate programmers who are used to a looser “bracket-encapsulated” language, it actually forces you to write more readable (and therefore, more maintainable) code.

Other than readability, Python’s clean syntax also means:

• You can write more code with less errors (because they’re so easy to spot). This often comes as a pleasant surprise to programmers migrating from C-style languages (take Eric Raymond for example).
• You end up typing less — No more semicolons or brackets, and fewer parentheses.
• Your eyes don’t have to move around as much to figure out what’s going on.
• Your first guess about what’s happening in a code-block is usually correct.

When you have time to kill, I’d recommend a stroll through Rosetta Code to compare how different languages “look” when tackling the same problem. Unless you just love brackets, I think you’ll find the non C-style syntaxes much easier to read.

» Python is more consistent than PHP

Continuing somewhat in the vein of readability is the topic of consistency. Since PHP’s lack of consistency has already been studied exhaustively by the Perl folks, I will spare you my rant and suggest you read theirs.

As a side note on this topic: I often hear PHP programmers talk about how awesome PHP’s documentation is in that you can open a web browser and just type “php.net/some_function” to get help. Well, documentation recall usually isn’t that big of a deal for me (because I have a somewhat photographic memory), but I will say that after switching to Python I found myself turning to its documentation significantly less than I had with PHP, simply because I didn’t have to keep reminding myself whether that infrequently used function was named some_function or somefunction. With Python, the function/method I need is usually named exactly what I expect it to be named, and returns exactly what I expect it to return.

Oh, and don’t even get me started on PHP’s recent namespace decision.

» However, PHP still excels in a few areas «

Having said all of that, there are a few areas where I believe PHP may still shine brighter than Python:

» PHP hosting support is may be more prevalent than Python

It’s practically unheard of to find yourself on a web host that doesn’t support PHP out of the box. However, this is becoming less and less of an issue since most Python web applications can now be deployed using tools such as FastCGI or mod_proxy (as opposed to the popular mod_wsgi setup, which often requires root access to configure). These days any “reputable” web host is probably going to support some sort of strategy for deploying Python web applications. Of course, this only really applies to shared hosting environments without root access. If you’ve got a VPS or dedicated server you’re fine.

» PHP is arguably “more seasoned” on the web than Python

The communities behind projects like Drupal and WordPress really stand out to me as examples of the maturity of PHP on the web. Although similar Python web projects have been slowly emerging (and Plone has been around for years, if that’s your cup of tea), they don’t really compete yet in my opinion.

Of course, I am only talking about specific web projects here. Language wise, Python has been around longer than PHP. Web 2.0 framework wise, Python’s offerings have been around about as long as PHP’s (pretty much every language had its own answer to Ruby on Rails in 2005).

» PHP seems easier than Python at first (and might be for simple deployments)

There’s something magical about throwing together a few quick index.php/about.php/contact.php files and uploading them to the httpdocs directory of your webserver and it “just working.” A lot of simple websites have no need for acronyms like MVC, ORM, and DRY, and in those cases PHP is an excellent “server-side extension” to HTML. However, if and when you begin to scale, you’ll either find yourself switching to a full-blown framework, or throwing one together to help facilitate your growth. At that point, you’ll probably begin discovering the “dark corners” of PHP, and may find yourself wishing you had “done it right” the first time.

» So, which is better? «

Remember, the point of this post is to solidify the fact that Python can be an excellent PHP replacement. When it comes to programming languages, “better” is often more a case of personal preference than anything else. However, to me the points discussed above make Python the better choice when it comes to what I like in a web development language.

So, is Python a better web development language than PHP?
Well, does Nike make a better shoe than Adidas?

The most honest answer is probably: “It depends.” Python definitely has some significant advantages over PHP in certain circumstances, but the same could probably be said of PHP in other circumstances (although limited to the web I imagine).

I hope this post has encouraged you PHP programmers out there to take another look at Python. It may take some getting used to (Python’s way of doing things is inherently quite different than PHP’s), but you will probably find yourself thanking me later.

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?

Well, in PHP the easiest way to make this happen would be a good-old-fashioned foreach loop:

foreach ($row as $val) {
    $out[$val[0]] = $val;
}

Not very “sexy” for something I find myself having to more often than I would like, but it works nonetheless.

Now, here’s where the beauty of Python kicks in. Python has a built-in feature called “comprehension” which allows you to modify and/or convert sets of data quickly and easily.

Remember what our original data set looks like? Here’s a refresher:

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

Now, in Python all we need to do is use the dictionary comprehension:

>>> out = {val[0]: val for val in row} # Python 3.X
# (or, for Python 2.X)
>>> out = dict((val[0], val) for val in row) # Python 2.4+
 
>>> print out
{1: [1, 'John Smith', 'admin'],
 2: [2, 'Jane Doe', 'superuser'],
 3: [3, 'Sam Jones', 'user']}

See how easy that was?

And what if I had a dictionary in the above format, and needed to turn it into the type of list I had previously? Well, I could simply use the list comprehension to re-generate this set of data as a list:

>>> print [val for val in out.values()]
[[1, 'John Smith', 'admin'],
 [2, 'Jane Doe', 'superuser'],
 [3, 'Sam Jones', 'user']]

This is an extremely simple comprehension example. For a deeper look, check out Wikipedia’s Python syntax page or the official Python documentation.

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:

# in myapp/development.ini (or production.ini, or whatever.ini you are using)
 
#sqlalchemy.url = sqlite:///%(here)s/devdata.db
sqlalchemy.first.url = sqlite:///%(here)s/database_1.db
sqlalchemy.second.url = sqlite:///%(here)s/database_2.db

Step 2: Change the way your app loads the databases

Now we need to instruct the app to load the multiple databases correctly. This requires telling base_config (in app_cfg.py) to load our own custom AppConfig with the proper multi-db assignments and a call to the model’s init_model method (more on that in Step 3):

# in myapp/config/app_cfg.py
 
# make sure these imports are added to the top
from tg.configuration import AppConfig, config
from pylons import config as pylons_config
from myapp.model import init_model
 
# add this before base_config =
class MultiDBAppConfig(AppConfig):
    def setup_sqlalchemy(self):
        """Setup SQLAlchemy database engine(s)"""
        from sqlalchemy import engine_from_config
        engine1 = engine_from_config(pylons_config, 'sqlalchemy.first.')
        engine2 = engine_from_config(pylons_config, 'sqlalchemy.second.')
        # engine1 should be assigned to sa_engine as well as your first engine's name
        config['pylons.app_globals'].sa_engine = engine1
        config['pylons.app_globals'].sa_engine_first = engine1
        config['pylons.app_globals'].sa_engine_second = engine2
        # Pass the engine to init_model, to be able to introspect tables
        init_model(engine1, engine2)
 
#base_config = AppConfig()
base_config = MultiDBAppConfig()

Step 3: Update your model’s __init__ to handle multiple sessions and metadata

Switching the model’s init from a single-db config to a multi-db simply means we have to duplicate our DBSession and metata assignments, and then update the init_model method to assign/configure each engine correctly:

# in myapp/model/__init__.py
 
# after the first maker/DBSession assignment, add a 2nd one
maker2 = sessionmaker(autoflush=True, autocommit=False,
                     extension=ZopeTransactionExtension())
DBSession2 = scoped_session(maker2)
 
# after the first DeclarativeBase assignment, add a 2nd one
DeclarativeBase2 = declarative_base()
 
# uncomment the metadata2 line and assign it to DeclarativeBase2.metadata
metadata2 = DeclarativeBase2.metadata
 
# finally, modify the init_model method to allow both engines to be passed (see step 2) and
# assign the sessions and metadata to each engine
def init_model(engine1, engine2):
    """Call me before using any of the tables or classes in the model."""
 
#    DBSession.configure(bind=engine)
    DBSession.configure(bind=engine1)
    DBSession2.configure(bind=engine2)
 
    metadata.bind = engine1
    metadata2.bind = engine2

Step 4: Have your model classes inherit from either DeclarativeBase or DeclarativeBase2, and use DBSession or DBSession2 as your database session handler

Now that the configuration has all been taken care of, you can instruct your models to use either the first or second DeclarativeBase and DBSession based on what DB engine you want it to access:

# myapp/model/spam.py (uses engine1)
from sqlalchemy import Table, ForeignKey, Column
from sqlalchemy.types import Integer, Unicode, Boolean
from myapp.model import DeclarativeBase
 
class Spam(DeclarativeBase):
    __tablename__ = 'spam'
 
        self.id = id
        self.variety = variety
 
    id = Column(Integer, autoincrement=True, primary_key=True)
    variety = Column(Unicode(50), nullable=False)
 
#---------------------------------------------------------------------#
 
# myapp/model/eggs.py (uses engine2)
from sqlalchemy import Table, ForeignKey, Column
from sqlalchemy.types import Integer, Unicode, Boolean
from myapp.model import DeclarativeBase2
 
class Eggs(DeclarativeBase2):
    __tablename__ = 'eggs'
 
    def __init__(self, id, pkg_qty):
        self.id = id
        self.pkg_qty = pkg_qty
 
    id = Column(Integer, autoincrement=True, primary_key=True)
    pkg_qty = Column(Integer, default=12)

Optional: Create and populate each database in websetup.py

If you want your setup_app method to populate each database with data, simply use the appropriate metadata/DBSession objects as you would in a single-db setup:

# in myapp/websetup.py
def setup_app(command, conf, vars):
    """Place any commands to setup myapp here"""
    load_environment(conf.global_conf, conf.local_conf)
    # Load the models
    from myapp import model
    print "Creating tables for engine1"
    model.metadata.create_all()
    print "Creating tables for engine2"
    model.metadata2.create_all()
 
    # populate spam table
    spam = [
        model.Spam(1, u'Classic'),
        model.Spam(2, u'Golden Honey Grail'),
    ]
    # DBSession is bound to the spam table
    model.DBSession.add_all(spam)
 
    # populate eggs table
    eggs = [
        model.Eggs(1, 12),
        model.Eggs(2, 6),
    ]
    # DBSession2 is bound to the eggs table
    model.DBSession2.add_all(eggs)
 
    model.DBSession.flush()
    model.DBSession2.flush()
    transaction.commit()
    print "Successfully setup"

Hope this helps! If you have any questions or suggestions please leave a comment below.

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…

Reason #1: “Whitespace done right” is actually a good thing

The first thing that people either absolutely love or adamantly hate about Python is the fact that code blocks are heavily tied to proper usage of whitespace. At first glance, this causes many curious onlookers from other languages to shy away from Python and continue in their bracket-encapsulated bondage. I’ll admit, at first I wasn’t too wild about these new restrictions either (I’m a programmer—I should be able to do my code how I want!); but the first time I had to go back to doing something in PHP for a client, I quickly realized I didn’t ever want to put anything inside brackets again:

# A sample function that's free from brackets, parenthesis, and semicolons!
def check_number(x):
    if type(x) != type(0):
        return "That isn't a number!"
    elif x % 2:
        return "This number is odd"
    else:
        return "This number is even"

Not only does this make Python source code incredibly readable, but you also end up typing less!

Reason #2: I almost always know what type of object I’m working with

One thing that always annoyed me about Perl was that you set an array or hash using the ‘@’ or ‘%’ sigils, but typically accessed them using the ‘$’ sigil. PHP simplified this a bit, but “$array = array();” could be a simple list or an associative array (known as a dictionary in Python). With Python on the other hand, the enclosure defines the type (for most built-in types at least), and since everything is an object there’s no need for silly sigils:

# the type of enclosure makes a distinction between a string , a list, and a dictionary
string = 'This is a string'
print string # prints 'This is a string'
 
list = ['This', 'is', 'a', 'list']
print list[0] # prints 'This'
 
dict = {'first_key': 'This', 'second_key': 'is', 'third_key': 'a', 'fourth_key': 'dictionary'}
print dict['fourth_key'] # prints 'dictionary'

On a somewhat related note, you can use these objects on-the-fly in your scripts without even having to assign them to a name. This isn’t usually practical of course (and may not be recommended), but it is possible:

print ['This', 'is', 'a', 'list'][1] # prints 'is'
print {'first_key': 'This', 'second_key': 'is', 'third_key': 'a', 'fourth_key': 'dictionary'}['first_key'] # prints 'This'

Reason #3: I can throw practically any type of object almost anywhere I want

Ok, so that might be a slight exaggeration; but the truth is that since Python treats everything as an object, you’re free to pack things away in the strangest places. A great way of demonstrating the power and flexibility of Python is in an example showing a few ways different types of objects can be stored and accessed:

# create a function
def hello_function():
    return 'Hello world!'
 
# create a file handle
hello_file = open('~/hello.txt', 'r')
 
# create a list with the function, the file handle, and a string
list = [hello_function, hello_file, 'Hello world!']
print list[0]() # prints 'Hello world!'
print list[1].read() # prints 'Hello world!\n'
print list[2] # prints 'Hello world!'
 
# or how about a dictionary?
dict = {'function': hello_function, 'file_object': hello_file, 'string': 'Hello world!'}
print dict['function']() # prints 'Hello world!'
print dict['file_object'].read() # prints 'Hello world!\n'
print dict['string'] # prints 'Hello world!'
 
# print types
print type(list[0]) # prints <type 'function'>
print type(dict['file_object']) # prints <type 'file'>
print type(list[2]) # prints <type 'str'> (str for string)

The shelve and pickle modules are also work a look if you like what you’ve just seen here.

Reason #4: The “in” operator simplifies sequences and makes membership testing a breeze

To explain the power of “in”, it’s probably easier to just show you a few examples:

'p' in "spam" # == True
'item1' in ['item1', 'item2'] # == True
'key' in {"key": 'value'} # == True
 
# prints anchor tags for a navigation
for title, link in {'Home': 'index.html', 'About': 'about.html', 'Contact': 'contact.html'}.iteritems():
    print '<a href="%s">%s</a>' % (link, title)

Reason #5: Slicing, stepping, and striding are a walk in the park

Probably my most-hated function in PHP is the substr() function. It should just be easier to access a parts of a string. Thankfully, in Python it’s a piece of cake:

#string slices and stepping/striding
string = 'This is a string'
 
print string[3] # prints 's'
print string[5:9] # prints 'is a'
print string[::2] # prints 'Ti sasrn' (a stride of 2 means print every other item)
 
# works on lists and dictionaries as well
list = ['This', 'is', 'a', 'list']
 
print list[::2] # prints ['This', 'a']

Reason #6-XX: Python makes programming fun again!

I could go on and on, but this post would be endless. As you can see, Python is a flexible, powerful, and fun programming language. For more Python concepts (I didn’t have time here to go into list comprehensions, generators, decorators, etc), I’d suggest you take a gander at Wikipedia’s page on Python syntax and semantics.

Finally, I’ll leave you with a few relevant links that are worth taking the time to check out:

• Bruce Eckel’s slides: Why I Love Python
• Python’s official tutorial (by Guido—Python’s creator)
• Dive Into Python – Free online book
• xkcd’s famous Python comic

The goal was to get the form to go through two layers of validation before passing:

1. Use the validation packages provided by TG (tw.forms and formencode)
2. If the first layer of validation passes, try to run the authorize.net charge. If this returns a response code of 1 (approved) then all validation has passed. Otherwise, invalidate the form and flash the authorize.net error.

tw.forms and formencode are awesome packages, but at first glance there didn’t seem to be “one obvious way” to do things. I found the documentation and tutorials to be scant at best, and eventually went to the TurboGears mailing list for help. In spite of the fact that I’d probably give TurboGears a “C” at best for its documentation (not to mention the availability of “verbose” tutorials), the folks on the mailing list and IRC channel (when it’s actually active) seem to be quite helpful.

Eventually (and with additional help from Google’s source code search) I was able to hack together something that worked as planned, and was overjoyed to observe chained validators in action. Below is some example code provided for your hacking pleasure. To download the full example file, see the links at the bottom of the post.

# FancyValidator to process the Credit Card using the authorize package
class ProcessCard(validators.FancyValidator):
    def _to_python(self, value, state):
        from authorize import aim as aim_api
 
        # Setup the aim Api object.
        aim = aim_api.Api(AUTHNET_LOGIN, AUTHNET_KEY, is_test=False)
 
        # Create a transaction against a credit card
        result_dict = aim.transaction(
            amount=u"16.00",
            card_num=unicode(value['card_number']),
            exp_date=unicode(value['card_expiry']),
            # ...and others...
            )
 
        if result_dict['code'] == '1':
            # success
            return value
        else:
            # failure
            raise validators.Invalid(result_dict['reason_text'], value, state)
 
class AuthnetForm(TableForm):
    submit_text='Process Card'
 
    validator = validators.Schema(
        chained_validators = [
            validators.CreditCardValidator('card_type','card_number'),
            validators.CreditCardSecurityCode('card_type','card_cvv'),
            # you could also add an expiry validator, but authnet will handle this for you
            ProcessCard()
        ]
    )
 
    class fields(WidgetsList):
        name = TextField(validator=validators.String(not_empty=True))
        # ...and others like address, city, state, zip...
        spacer = Spacer(suppress_label=True)
        card_type = SingleSelectField(options=[('visa', 'Visa'), ('mastercard', 'Master Card'), ('discover', 'Discover'), ('amex', 'American Express')], validator=validators.NotEmpty)
        card_expiry = CalendarDatePicker(date_format="%m/%Y", validator=validators.NotEmpty)
        card_number = TextField(label_text='Card #', validator=validators.NotEmpty)
        card_cvv = TextField(label_text='CVV Code', validator=validators.NotEmpty)
 
authnet_form = AuthnetForm('authnet_form', action=url('/authnet/process/'))

Links of interest:

• Download the authnet.py file
• This post’s original Google group thread
• The Authorize package

Ok, let me back up before I get ahead of myself…

I’ve been a web developer for over 10 years now. When it comes to web programming languages and platforms, I’ve been around the block a bit: Back in the 90s I was building shopping carts from scratch using Perl (ouch!). From Perl, I eventually migrated to PHP which usually made things much easier. From time to time I would play around with Rails; but I never could stomach Ruby’s syntax (I think it reminded me too much of Perl). Even though I never felt like I really “clicked” with PHP, I eventually settled into a few PHP frameworks I liked and finally called myself a PHP developer.

Then one day I stumbled across Python, and it was love at first sight. I quickly vowed that I would soon be doing 99% of my web development in my newfound favorite language, but was disappointed to discover that (at that time) the available web frameworks were either ugly or poorly documented/supported. Reluctantly I returned to PHP, unable to justify moving away from the “quick & simple” nature of what I was used to with PHP and the frameworks I was used to.

I’m not one to give up easily though, and on a recent “re-visit” of the Python web framework scene I was excited to see that things had changed dramatically: Django’s community had exploded and its documentation looked rock-solid. Pylons had cropped up as a serious WSGI-based contender (and modeling quite a bit of it’s functionality after Rails). But what really caught my attention was the (at the time) upcoming TurboGears v2.0 release.

What made TG2 stand out to me was its attempt to build a “best-of-breed” module-set on top of Pylons. Mark Ramm (the current leader of TG development) has been quoted as comparing TG2 to Ubuntu in that  “TG 2 is to Pylons as Ubuntu is to Debian.” The sound of that intrigued me, and I started playing around with the TG 2 Betas (and liking what I was seeing!).

Recently one of my clients asked me to whip up a medium-sized project with various amounts of CRUD and Ajax. Ironically, that very same day TurboGears’ v2.0 release went gold. Seeing this as my opportunity to finally begin transitioning into the Python world with a stable “next-generation” Python web-development framework, I have decided to implement my latest project using TurboGears 2. Could this be the beginning of the rest of my life?

I will keep you posted on my progress and what I encounter along the way (good, bad, and ugly). Keep it here for what will likely be an interesting adventure.

Related links of interest:

• TurboGears
• Introducing Three Python Web Frameworks