-> Yes, somehow. It is really the marketing – this is the only part where we should learn from Ruby, how to hype and push something..

-> And perhaps also a posterboy like David Heinemeier-Hanson is missing – instead of boygroup appeal our outstanding persons are more of the type “lumberjack” :) Just see this: http://www.flickr.com/photos/termie/sets/72157616044454732/ :)

I am just joking, but the truth is that the Python community sucks at marketing, and pushing more into the public.. It is frightening every time how less PHP and Ruby guys know from Python, and also how many misinformation is out there..

Blog posts like yours, for example the benchmarks where people can see how performant web stuff in Python is running, helps, but sometimes it has to be more than facts.

:)

1. You’ll find that performance-critical parts of Python libraries are often implemented in C, also. In fact, Python makes this easier because you can treat C extensions to Python just like regular Python libraries. If you ever really need to optimize your code beyond what Python lets you do, you can always fall back to C.

It’s usually better to optimize other things first, though. The language is usually the last things you need to optimize in any given scenario.

You’ll also note that servers like Paster are usually put behind a reverse proxy (Apache, nginx or lighttpd) that takes care of static files and thus reduces the load on the app. Some are faster than others, too. For most websites, you probably don’t need to worry, though. Someone who should know these things once told me you can go a long way just using Python’s built-in wsgiref server to run your wsgi apps.

2. The GIL shouldn’t worry you. While there is a lot of drama about it, you probably won’t encounter any such problems in practice. Most of the criticism is theoretical or only relevant for high-performance scenarios.

3. If the prospect of cleaner, more straight-forward code and a much saner object model (first-class functions, etc) can’t convince you, nothing will. You should work with whatever language is easiest on your brain. For some people this is Python. For some people this is Ruby. Heck, for some people this is Perl.

You should give it a try, if only for the sake of learning something new and keeping your mind fresh (it’s a good idea to try out new languages at least once per year to keep up with the times and broaden your horizon). Maybe you’ll like it. Maybe you won’t.

You should also try Ruby. It has a lot in common with Python but is completely different (if only in its philosophy).

This article seems to be aimed more at people who only stick with PHP because they don’t know of any alternatives. So if you use PHP because you made a conscious and educated choice, more power to you. But if you only stick with PHP because you haven’t written even a simple web app in another language, you should go and do that right now.

I really like Python for desktop development, so I’d like to use the nice Python syntax for web development, but I also really love the way PHP can be mixed with HTML.

thanks in advance

I’ve been interested in Python for a while now, having spent almost a decade with PHP. Seems a rather nice language and I can certainly see its benefits over PHP.

However, I wonder about some things, for instance:

1. Being developed for web, PHP has some inherent solutions for common requirements like session management, fcgi interfacing. Those are done in C, in the core of PHP, while Python requires middleware written in Python (e.g Beaker, Paster’s HTTP server or wsgi/fastcgi implementation).

I wonder if there is a significant performance hit for Python because of that.

It is true that there exists some theoretical threshold of app complexity above which PHP’s requirement to bootstrap entire application (the part thereof required to process the request) becomes significant performance bottleneck compared to load-once apps like those written in Python, which offsets any speed benefits of C code inside PHP. But I wonder how significant this is in practice? Even the most complex app has little to do in PHP. They all wait on I/O of whatever sort, even if the request generates dozens or more queries (take Drupal modules for example, at some point there can be over a hundred of queries per request). It is the stateless nature of HTTP that brings all languages to the same level requiring “third party” intervention like memory cached session management or data layers, database I/O, etc…, and number crunching algorithms can anyways be moved to C both in Python and in PHP. That being the common denominator, the true differences are then shown in parts that are done in the language itself: in this case the aforementioned session management, fastcgi interfacing (or in Python, entire HTTP server written in Python — Paster’s), etc…

2. GIL worries me. While it is true that, especially for web applications, threads usually wait on I/O so GIL is not that much of a problem, I am not so convinced for practical implementations of apps that require performance and cache data wherever possible (reducing I/O wait). There, the GIL definitely impairs performance, but I wonder how significant?

Also, SMP deployment with PHP is as simple as instructing PHP to spawn more processes. I’m assuming fastcgi implementation since Apache (and it’s mod_php) should not coexist with “performance” in the same sentence. :)

It is as easy with Python (for instance using Paster), but each of those instances is interfaced with the web server through Python code, not C implemented code. Evenmoreso if proxying is used for load balancing.

So if syntactic sugar present in Python is not sufficient to move us from PHP to Python (and in my case, I can name two: decorators and indentation/lack-of-$;{}, everything else is more or else the same), is there anything else that Python can offer?

Thank you. Good question, and perhaps I will do a “part 2″ of this post going into more detail about that.

In short I would suggest you check out a simple Python framework (Bottle is a great option) to familiarize yourself with how Python does things differently.

Like PHP, the Python interpreter process can be run with Apache (using mod_wsgi). However, unlike PHP you will typically separate your “controller” and “view” code instead of writing HTML around <? and ?> type tags. While this may seem complicated at first, it actually lends itself to a better code layout. In PHP terms, it’s much like the process of using Smarty templates (PHP-only files as your “business” code, which then process and render your Smarty “presentation” code).

Several Python template options exist, with the most popular ones probably being Mako (super-fast), Jinja (quick & simple), and Genshi (slower but XML-based).

There are of course many options for deploying Python web applications, with mod_wsgi only being one of them. Typically during the building & testing phase, you will run your Python web app on some sort of built-in WSGI implementation and load it locally (if you’re familiar with Rails, it’s like running your Rails app locally and loading it on port 3000).

Hope this helps!