Not only have most of the frameworks seen new releases since the last revision, but I finally decided to move all of the tests over to Amazon’s “release” version of the Ubuntu LTS AMI.

Below is a quick summary of what’s new in this revision:

• All tests were performed on the updated Ubuntu LTS AMI (ami-fbbf7892 ubuntu-images-us/ubuntu-lucid-10.04-amd64-server-20110719.manifest.xml)
• The updated AMI was configured with Python 2.6.5, PHP 5.3.2, Ruby 1.9.2p290, Apache 2.2.14 (default config), mod_wsgi 2.8 (embedded mode), and mod_passenger 3.0.9
• Rails 2.x and 3.0 were dropped from the “full stack(ish)” tests in favor of Rails 3.1.
• CakePHP 1.2 was dropped from the PHP tests in favor of 1.3, but Symfony and Yii were added as they seem to have considerable market share.
• CakePHP’s caching engine was incorrectly configured during the last round of tests, and this has been corrected.

Circle me on Google+ to keep track of further updates, and feel free to contact me there with any questions or comments.

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.

A lot of work has been going into the TG docs in preparation for the upcoming v2.1 launch, and one little gem that was recently added was the Pagination Quickstart (thanks Lukas). While this sent me down the right path towards pagination perfection, there were a few things that came up that I felt like deserved further explanation:

1. The @paginate() decorator is an extremely simple wrapper for the paginate webhelper module.
2. When paginating SQLAlchemy queries, paginate runs a duplicate count() query to figure out its current position in the data collection. While the magic of this is nice, the possible performance issues with duplicating complex SQL queries on a high-traffic website could be undesirable.
3. It’s common to have controller methods dynamically switch to a “feed template” when doing AJAX pagination. Don’t worry, paginate + override_template makes this a piece of cake!

The @paginate() decorator makes pagination a breeze

The @paginate decorator is a wrapper for the paginate module that can be added to your controller methods. Simply specify your data collection’s name as the first argument of the decorator, and pagination is “automagically” setup for you.

An example controller method with pagination would look like this:

# dead-simple pagination in TurboGears 2
 
@expose('myproject.templates.posts')
@paginate("posts")
def posts(self):
    posts = DBSession.query(Posts)
    return dict(posts=posts)

Really? That was easy!

The documentation on this decorator seems quite clear to me, so instead of repeating its content here I will simply give you a link for further reading.

SQLAlchemy pagination performance wizardry

The main issue here is that the paginate module has to figure out its current position in the data collection in order to be able to spit out the right “chunk” of data (as well as to provide you with fancy stuff like “page 3 of 6″). So, by default when you give it an SQLAlchemy query object, it runs a count() query to figure this out. This results in two practically identical SQL queries (one to get the total count, and the other to return your actual collection of data). While this may not be an issue on simple queries, duplicating complex queries on a high-traffic website could be disastrous.

Remember, magic can be unpredictable, so before we dive into this topic there are a few things you should take into consideration:

• This technique is not compatible with the @paginate() decorator due to the fact that the current page arg isn’t passed into the controller method when using the decorator, so be ready to get your hands dirty with the full-blown paginate module.
• The SQLAlchemy all() query method results in immediate query execution. This may have undesirable side-effects.
• I’m sure there is a cleaner/sexier way to do this, but for the sake of time and in an effort to be verbose this is what I have come up with so far. Please leave a helpful comment below if your magic is cleaner than mine.

Ok, so now that we are familiar with the problem, what is a good solution? Well, a rough hack to work around this issue is to use SQLAlchemy’s limit() and offset() query methods combined with the all() method to get SQLAlchemy to return a list instead of a query object. This puts paginate to work on the list instead of on the database, avoiding the extra count() query. However, as tricky as this may be, there are still problems:

1. In order for paginate to calculate a correct current position based on the “page” it thinks it’s on, you’ve got to pad the beginning of the list you send to the paginate.Page() method with enough items to accurately reflect the “current” size of the data collection.
2. In order for paginate to know there are more records waiting to be loaded, you’ve got to pad the end of the list you send to the paginate.Page() method with at least one more item than each page’s specified item limit.

This may seem confusing at first, but an example controller method should help clear things up for you:

# import the paginate webhelper
from webhelpers import paginate
# specify the number of items you want per page
items_per_page = 20
 
@expose('myproject.templates.posts')
def posts(self, page=1):
    # specify the limit, plus 1 so the Page() method can tell if extra data is available
    limit = items_per_page + 1
    # specify the offset to start with
    offset = (int(page) - 1) * items_per_page
 
    # if the offset is greater than 0, we have to pad the beginning of the list
    if offset: posts = [x for x in xrange(offset)]
    # otherwise we're starting at the beginning (with an empty list)
    else: posts = list()
 
    # load the DB data into the list
    posts.extend(DBSession.query(Posts).limit(limit).offset(offset).all())
 
    # setup the pagination object
    pagination = paginate.Page(posts, page, items_per_page=items_per_page)
    # either use tmpl_context or return the object in the return dict
    tmpl_context.pagination = pagination
 
    return dict(posts=pagination.items)

Voilà! Now that you’re dealing with a list, pagination should work as expected without the extra “count()” query.

Use override_template() for dynamic template rendering

AJAX pagination is a common practice and often provides a richer user experience than “static” pagination. Fortunately, AJAX pagination is almost as easy to setup as normal pagination, and only requires a few extra tweaks to an already simple configuration.

The only “tricky” thing here is if you’re accessing the same controller method for partial data as well as the full page. In such a case, you’ll need to have the controller method render two separate templates depending on if you’re asking for the “full” page, or just the listing of data. Don’t worry though, paginate automatically provides you with a “partial” arg that you can check against, and override_template() allows you to override whatever template you have defined in the @expose() decorator.

Modifying the previous example’s controller method for this type of functionality looks like this:

# add the override_template import
from tg import override_template
 
# add the "partial" arg to the controller method
def posts(self, page=1, partial=0):
    # ...snip...
 
    if partial:
        override_template(self.posts, 'mako:myproject.templates.post_feed')
 
    return dict(posts=pagination.items)

More information on override_template() can be found in the docs.

I hope this tutorial has been helpful. I will be submitting a TG docs pull request soon, so please leave comments if you have any suggestions or feedback.

[This post is the continuation of a series. Please read Round 1 first if you are just now joining us.]

In Round 1, PHP was looking like quite the tortoise of the group. However, if you’re familiar with some of the core differences between Python & PHP, you’ll know that Python has been “cheating” slightly.

Let me explain: By default, Python compiles each script into bytecode on its first execution, allowing this bottleneck to be skipped on subsequent runs. PHP, however does not perform this type of optimization by default (in the 5.x line at least), so the PHP interpreter must re-compile each file every time it is run. As you can imagine, this can give PHP (without an accelerator) a huge disadvantage when compared to languages such as Python.

With this in mind, I have decided to take Round 2 to focus solely PHP. This will hopefully provide a clear picture of the benefits of PHP bytecode caching (at least when it comes to page-views — the memory benefits are a whole other story), and give you an idea of PHP’s performance with the help of an accelerator.

There are many PHP accelerators available, but I have chosen APC for use here (mostly due to its inclusion in the upcoming PHP 6 core).

What you should know about Round 2:

1. The hardware/software platform is the same as in Round 1.
2. PHP has been upgraded to v5.2.9.
3. The APC tests are using APC v3.0.19.
4. ApacheBench was run with -n # -c 10, with -n usually being 5000 or 10000, depending on the test subject’s speed.
5. Each test was run several times to make sure that there were no anomalies, with the “optimum average” chosen as the numbers represented here.
6. In an attempt to try to make these tests more scientific, I am now including the source code for each test (minus the CMS tests, which were performed on a standard install).

My apc.ini settings:

extension = apc.so
apc.enabled = 1
apc.shm_size = 96
apc.include_once_override = 1
apc.mmap_file_mask = /tmp/apc.XXXXXX

Raw PHP – php_test_src.zip

To investigate the speed of “raw PHP”, I created a couple of minimal PHP scripts that printed out a simple “hello world”, and read a few lines of text from a database. Take a look at the test source code for reference.

APC Disabled

The 'hello world' test:
 
Document Path:          /hello.php
Document LENGTH:        12 bytes
Requests per second:    4199.43 [#/sec] (mean)
 
The simple database bold;">QUERY test:
 
Document Path:          /hello_db.php
Document LENGTH:        2524 bytes
Requests per second:    2797.54 [#/sec] (mean)

APC Enabled

The 'hello world' test:
 
Document Path:          /hello.php
Document LENGTH:        12 bytes
Requests per second:    6618.42 [#/sec] (mean)
 
Simple database bold;">QUERY test:
 
Document Path:          /hello_db.php
Document LENGTH:        2524 bytes
Requests per second:    3713.99 [#/sec] (mean)

Right out of the gate, we can see that APC gives PHP a significant boost.

Of course, a script that simply does a “echo ‘hello world’” isn’t really practical, so let’s take a look at a couple of popular PHP frameworks to see what a full stack looks like.

CakePHP v1.2.5 – cakephp_test_src.zip

CakePHP was the slowest test subject by a large margin in Round 1, but if you take a look at the caching section of its core configuration file you can see that the developers have written it with acceleration in mind. It includes special configuration directives for not just APC, but also Xcache and Memcache.

Still though, without acceleration CakePHP is a sad story indeed:

APC Disabled – File Caching Engine (default)

The RETURN 'hello world' test:
 
Document Path:          /hellos/
Document LENGTH:        13 bytes
Requests per second:    45.25 [#/sec] (mean)
 
The template hello world test:
 
Document Path:          /hellos/hello
Document LENGTH:        931 bytes
Requests per second:    39.90 [#/sec] (mean)
 
The simple database bold;">QUERY test (bold;">USING the ORM):
 
Document Path:          /hellos/hello_db
Document LENGTH:        2469 bytes
Requests per second:    38.80 [#/sec] (mean)

However, with the help of APC things finally begin to look reasonable:

APC Enabled – APC Caching Engine (in core.php)

The RETURN 'hello world' test:
 
Document Path:          /hellos/
Document LENGTH:        13 bytes
Requests per second:    140.98 [#/sec] (mean)
 
The template hello world test:
 
Document Path:          /hellos/hello
Document LENGTH:        931 bytes
Requests per second:    120.04 [#/sec] (mean)
 
The simple database bold;">QUERY test (bold;">USING the ORM):
 
Document Path:          /hellos/hello_db
Document LENGTH:        2469 bytes
Requests per second:    117.56 [#/sec] (mean)

As you can see, APC increases CakePHP’s speed about threefold in these examples. These results may or may not be acceptable to you (remember that we are running these tests with a concurrency of 10), but I felt much better about CakePHP after pairing it with APC.

Kohana v3.0 – kohana3_test_src.zip

Kohana (a divergent of CodeIgnitor) is a much more lightweight PHP framework than CakePHP, but still gives you a pretty full featureset. Since v3.0 was released shortly after Round 1, I decided to use the new version for the tests here in Round 2.

It should be noted that although file caching is enabled in a default CakePHP install, Kohana’s caching is disabled by default. I have included a couple of tests with caching disabled here to exhibit the performance of a default Kohana install.

APC Disabled – Caching Disabled (default)

The RETURN 'hello world' test:
 
Document Path:          /hello/INDEX
Document LENGTH:        12 bytes
Requests per second:    86.73 [#/sec] (mean)

APC Disabled – Caching Enabled (bootstrap.php)

The RETURN 'hello world' test:
 
Document Path:          /hello/INDEX
Document LENGTH:        12 bytes
Requests per second:    180.50 [#/sec] (mean)
 
The template hello world test:
 
Document Path:          /hellos/INDEX
Document LENGTH:        930 bytes
Requests per second:    162.27 [#/sec] (mean)
 
The simple database bold;">QUERY test (bold;">USING the Database module):
 
Document Path:          /hellodb/INDEX
Document LENGTH:        2525 bytes
Requests per second:    113.92 [#/sec] (mean)
 
The simple database bold;">QUERY test (bold;">USING the ORM module):
 
Document Path:          /helloorm/INDEX
Document LENGTH:        2525 bytes
Requests per second:    99.73 [#/sec] (mean)

As you can see, even without APC Kohana is quite a bit faster than CakePHP.

APC Enabled – Caching Disabled

The RETURN 'hello world' test:
 
Document Path:          /hello/INDEX
Document LENGTH:        12 bytes
Requests per second:    125.93 [#/sec] (mean)

APC Enabled – Caching Enabled (bootstrap.php)

The RETURN 'hello world' test:
 
Document Path:          /hello/INDEX
Document LENGTH:        12 bytes
Requests per second:    280.67 [#/sec] (mean)
 
The template hello world test:
 
Document Path:          /hellos/INDEX
Document LENGTH:        930 bytes
Requests per second:    253.50 [#/sec] (mean)
 
The simple database bold;">QUERY test (bold;">USING the Database module):
 
Document Path:          /hellodb/INDEX
Document LENGTH:        2525 bytes
Requests per second:    173.28 [#/sec] (mean)
 
The simple database bold;">QUERY test (bold;">USING the ORM module):
 
Document Path:          /helloorm/INDEX
Document LENGTH:        2525 bytes
Requests per second:    153.90 [#/sec] (mean)

Although not a threefold gain as with CakePHP, Kohana with APC+caching definitely makes a good attempt at shortening the gap seen in Round 1 between the PHP frameworks and the offerings from other languages. Of course, if raw speed is what you’re looking for, there are faster PHP frameworks available (note that the benchmarks on that page were run on a completely different setup and should not be compared with any of the numbers here).

Next, let’s take a look at how APC enhances the performance of a few of PHP’s heavyweights.

WordPress v2.8.4 (default install)

Although I’ve heard that WordPress has a built-in caching setting, a quick glance at wp-settings.php did not reveal anything. So, there are simply two WordPress tests—with APC, and without:

APC Disabled

Document Path:          /
Document LENGTH:        5519 bytes
Requests per second:    24.80 [#/sec] (mean)

APC Enabled

Document Path:          /
Document LENGTH:        5519 bytes
Requests per second:    74.00 [#/sec] (mean)

Joomla v1.5.14 (default install, without sample data)

The results of these tests were quite disappointing to me, and made me wonder if I was doing something wrong. Sadly, it looks as though Joomla is quite the slow one of the bunch.

APC Disabled

Joomla Caching Disabled (DEFAULT):
 
Document Path:          /
Document LENGTH:        4006 bytes
Requests per second:    27.90 [#/sec] (mean)
 
Joomla Caching Enabled (File):
 
Document Path:          /
Document LENGTH:        4006 bytes
Requests per second:    31.46 [#/sec] (mean)

APC Enabled

Joomla Caching Disabled:
 
Document Path:          /
Document LENGTH:        4006 bytes
Requests per second:    41.27 [#/sec] (mean)
 
Joomla Caching Enabled (APC):
 
Document Path:          /
Document LENGTH:        4006 bytes
Requests per second:    45.01 [#/sec] (mean)

Drupal v6.14 (default install, clean URLs disabled)

Drupal has several caching settings, so I decided to see what each one would look like and how much of a difference “aggressive” caching made.

APC Disabled

Drupal Caching Disabled (DEFAULT):
 
Document Path:          /
Document LENGTH:        5548 bytes
Requests per second:    36.72 [#/sec] (mean)
 
"Normal" Drupal Caching:
 
Document Path:          /
Document LENGTH:        5548 bytes
Requests per second:    289.69 [#/sec] (mean)
 
"Aggressive" Drupal Caching:
 
Document Path:          /
Document LENGTH:        5548 bytes
Requests per second:    335.68 [#/sec] (mean)

APC Enabled

Drupal Caching Disabled:
 
Document Path:          /
Document LENGTH:        5548 bytes
Requests per second:    83.93 [#/sec] (mean)
 
"Normal" Drupal Caching:
 
Document Path:          /
Document LENGTH:        5548 bytes
Requests per second:    498.37 [#/sec] (mean)
 
"Aggressive" Drupal Caching:
 
Document Path:          /
Document LENGTH:        5548 bytes
Requests per second:    564.48 [#/sec] (mean)

As you can see, Drupal’s caching (especially when combined with APC) changes things drastically. These results seem to indicate that Drupal’s caching does a great job of allowing the CMS to get out of the way.

Closing thoughts

• The benefits of a PHP accelerator are really too good to pass up. Even without written-in caching, an accelerator can give your code a significant boost.
• While these tests have only really explored the impact on website page-load times, a PHP accelerator typically also cuts down on the amount of memory used by your PHP scripts.
• PHP 6 has promised to fix a lot of things, including the lack of built-in bytecode caching. It will be interesting to revisit these tests in a few years (?) to see how much optimization the new version brings to the table.

Can’t get enough of this madness? Just wait until you read Round 3!

(Note: Please don’t leave benchmarking requests as comments. If you’d like me to take a look at your favorite framework, direct message me on twitter. Thanks!)

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

I’ve been playing around with Mozilla’s latest release, and I’ve got to say: Firefox is where it’s at! If anyone out there is still using Internet Explorer, you deserve anything that comes to you by way of malware, adware, spam, viruses, etc. Seriously, get with the times and install a real browser! And to you Apple/Mac users out there: Yeah, Safari is nice, but don’t let pride keep you from branching out of familiar territory.

One of the great thing about Firefox is its add-ons, and I’ve decided it’s time to dedicate a post to a few of my personal favorites:

Adblock Plus

To me, Adblock Plus is THE most incredible thing about Firefox (and its #1 selling point). This add-on actually strips about 99% of “web spam” and annoying banner ads from websites *before* they load into Firefox.

Note: Some web sites are financed soley by revenue from visitors loading ads on their sites. Keep in mind that stripping out ads may in some cases also affect the income generated by your favorite blog/social site.

Flashblock

Similar to Adblock, Flashblock turns flash elements into “play buttons” instead of auto-playing all those crazy flash items on pages.

Firebug

To me, the 2nd most important thing about Firefox. As a web developer I’m always having to dissect a page’s DOM, or do extra debugging on a JavaScript function. Firebug gives me complete access, control and information about a web page.

Tamper Data

A more technical add-on, Tamper Data allows you to view and modify request headers and form submits (as well as any other communication between the client & server). Very geeky, but very powerful.

FireFTP

FireFTP turns Firefox into a full-featured FTP client. A must, especially if you’re a Windows user (mounting FTP sites in Windows Explorer is still weird)

Honorable mention: SQLite Manager, ChatZilla, FoxyProxy, Morning Coffee, YSlow, User Agent Switcher

Give these a whirl… you’ll be glad you did!

- Seth

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