Adding to my last entry, and inspired by Sam Bull's Django entry, following is a QP web application framework-based entry in Eric Florenzano's multi-language programming meme.

# ~/qp_sites/florenzano/slash.qpy
"""
An entry in Eric Florenzano's programming meme...
To run:
    qp florenzano start
"""
from qp.fill.css import BASIC_FORM_CSS
from qp.fill.directory import Directory
from qp.fill.form import Form
from qp.pub.common import header, footer, page
from qp.pub.publish import DurusPublisher

class SitePublisher (DurusPublisher):

    configuration = dict(
        live_host='your_live_host',
        durus_address=('localhost', 7011),
        http_address=('', 8011),
        )

class SiteDirectory(Directory):

    def get_exports(self):
        yield ('', 'hello', 'Hello', None)

    def hello:xml(self):
        form = Form()
        form.add_string("name", title="Your name", size=20,
                        required=True)
        form.add_int("age", title="Your age", required=True)
        form.add_submit("Say Hello")
        if not form.is_submitted() or form.has_errors():
            return page('Say hello', form.render(),
                        style=BASIC_FORM_CSS)

        # The form has been submitted
        header('QP hello example')
        '<ul>'
        for age in range(form.get('age')):
            '<li>%s) Hello, %s.</li>' % (age, form.get('name'))
        '</ul>'
        '<p><a href="">Try again...</a></p>'
        footer()

Liars, or incompetents, the Conservatives can't be trusted or believed in or out of government.

We've just completed an election which Stephen Harper promised we wouldn't have until 2009. Harper broke his own promise and his own law, merely to try to gain partisan advantage - something his own law was to prevent from happening in the future.

All through the election Harper and Finance Minister Jim Flaherty stressed that the land was strong, that there were no real economic issues threatening Canada. Only after headline after headline made the news of impending economic doom in the U.S., and it became more than clear that the same sorts of troubles were, and will continue to, affect Canada, did Harper and Flaherty even acknowledge the problem. They almost lost the election. Perhaps they'll lose the country.

Now, immediately after the election, Flaherty has finally awoken to the economic crisis and wants us to believe they've been proactive on the file all along. This is nothing but raw bull manure.

During the election Harper and Flaherty said no-way, no-how would we see the government of Canada go into deficit spending, even though in four of six months so far the country has been in deficit, spending is up, revenue down, and public debt is rising, not falling. This will only be worse going forward as the economic picture before year end in March will have deteriorated significantly.

After the election now Harper is now calling potential deficit spending as "essential".

Canadians can't believe a word these jokers have to say before, during, or after an election.

With the final release of Python 3.0 arriving soon, more developers are discussing transition strategies to move from "2 to 3". Perhaps some should consider a strategy to support "2 and 3".

Fabio Zadrozny noted yesterday a number of tips or workarounds for simultaneously supporting applications in both Python 2.x and 3.x - a great notion - maybe a 2 and 3 (as opposed to a 2 to 3) best practices FAQ should be started somewhere. I've got a few to add to the collection which I'll post in due course.

I'm not sure that all applications will be able to neatly support both major versions of Python with the same code base, although it does seem to be to be an objective worth due consideration.

Should application code bases co-exist on both? Perhaps the pivot point is a judgement call on how many compatibility shims one has to shove into the code base to support both.

In Python 3000 Status Update Guido van Rossum outlines a transitional development approach, suggests porting projects to 2.6 first, using the command line flags to show 3.x warnings and deprecations, as an aid to getting to 3.0. Subsequently in Python 3000 and You (See also Guido's presentation [PDF]) he urged developers to be considerate of the users of their APIs when moving up to 3.0. This appears to be the approach the Twisted folks have chosen to follow.

Still, despite some consternation over py2/py3 migration or dual-support strategies having been expressed in the pythonosphere, successful examples of packages with dual 2/3 support may prove to be more common than was anticipated.

As an example we can look at QP and its supporting friends QPY, Durus, Dulcinea, and Sancho, all of which will support from the same code base both Python 3 and 2.x when version 2.1 of the QP web application framework is released upon Python 3.0's release. You won't find a lot of complicated hacks or compatibility shims lurking in every module.

Given that the QP-suite encompasses a full stack web application development environment including a Python object database engine, it would seem to be self-evident that it is possible to write non-trivial applications that simultaneously, and cleanly, support the old and new eras of Python. Kudos to the Mems-Exchange folks!

Kudos also to the Python language developers. On balance I really like Python 3 and look forward to seeing increasing numbers of packages available on it. If I was forced to single out one change which I like the best, it would be that the Unicode type / u'' has been done away with. All strings are now "unicode" and utf-8 as a default encoding makes so much sense in this day and age. Unlike in the 2.x world, Python 3 users will generally avoid problems with mixing encoded and unencoded text. Of course this comes with a price - any code which used Unicode and encodings will need updating - but its a price well worth paying for the long run.

For those who remain confused over Unicode in 2.x, I recommend you install a sandbox Python 3 environment and play. Visit the What is Unicode? page and grab some funky UTF-8 encoded strings and start playing in 3.0 and notice how much less thinking you need to do...

There are other cross-compatibility hurdles many non-trivial applications and scripts will need to leap and I'll try to document those few I've jumped personally. In the next instalment lets dive right in and deal with using metaclasses in both Python 2 and 3. It is easier than you might suspect.