If you're like me, one of the first things you do when starting a new
web application project is set up a CSS alternative such as LESS or
SASS/SCSS. Those who aren't particularly fond of JavaScript might also
tend to add CoffeeScript. These "metalanguages" can assist in making
client-side/asset code more pleasurable to work with, as they typically
provide functionality that's "missing" in the the languages they get
interpreted into.

Some frameworks (e.g. Ruby on Rails) give you support for these
alternatives out-of-the-box, but in the land of less opinionated
software things can require a bit more work. Since I am personally a fan
of the
Pyramid
web framework, I've used the
pyramid_webassets
and pyramid_fanstatic
packages in the past to provide this support. However, these packages
are so powerful and comprehensive that they can also tend to be somewhat
involved in regards to configuration, so I recently decided to roll my
own Pyramid
add-on: pyramid_assetmutator

Although definitely not as "feature-full" as the packages I have
mentioned earlier, as of this writing it provides the following:

Support for piping (a.k.a "mutating") assets through pretty much any
command you like (its core functionality is quite rudimentary).

The ability to specify whether to have your assets "mutated" during
each request, or on each "application boot" (typically best for prod
setups).

Every so often I find myself working on that odd job that requires
syncing files with Amazon's S3. In the beginning, I tried some of the
various S3 FUSE interfaces—hoping for something that would play nice
with rsync—but FUSE's stability always left something to be desired and
more often than not I'd be left with that one transfer that never would
quite finish correctly.

Eventually I discovered boto and
settled in to using a hacked together (but stable) Python/boto solution
for these type of tasks—all the while wondering why nobody took the time
to write a "real" rsync-like client for S3.

Well, this last time around I finally decided to stop whining and take
matters into my own hands. After a couple of late nights fleshing out my
original boto solution, I'm happy to announce what I'm calling "boto
rsync"—an rsync like wrapper for boto's cloud storage interfaces (both
S3 and Google Storage).

Due to the popularity of these posts, I have decided to move
all of the benchmarking information over to its own dedicated page.
Please see the new framework shootout page for the latest
information.

This post is the continuation of a series. Please read Round 1, Round 2, and Round 3 first if you
are just now joining.

While I had originally intended for round 4 to showcase how
microframeworks are changing the way we do "quick and dirty" web
development (and how they make using PHP as "an extension to HTML" old
hat), my current programming habits have kept me involved in the more
"full-stack" framework solutions. So, rather than spitting out various
benchmarks of frameworks that I have little or no interaction with, and
since enough time has passed since the last "shootout" that the
landscape has changed a bit (with the introduction of
Pyramid and the release of Rails 3), I
have instead decided to showcase the most recent data on the frameworks
that I personally find myself in contact with on a regular basis.

Warning: Everything is different this time around.

These benchmarks were all run on a fresh Amazon EC2 instance in order to
(hopefully) achieve a more isolated environment. Obviously, since these
benchmarks have all been run on a completely different box than any of
the previous rounds, no previous data should be compared with these
numbers.

I recently sat down to coffee with a new acquaintance of mine who spends
much of his time implementing F/OSS projects at non-profit
organizations, and who had just stepped into a lead web developer
position using PHP. After sharing pleasantries we began trading stories
and talking about each of our "tools of the trade." When I mentioned
that I used to do most of my web development in PHP, but have spent the
past year or so trying to move as completely as possible to Python, his
response was: "Huh, I have never really thought of Python as a PHP
replacement."

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.