Since the template can’t contain any view-logic, it ends up in a separate place (In PHP code). This makes the separation between presentation and logic airtight, which was the main idea of template engines in the first place. Another benefit is that since there is no string-level manipulation, it is virtually impossible to inadvertently get injections-type security breaches.

The template may be unaware of the view-logic, but the opposite can’t be said. To bind values to the template, the view-logic needs to be aware of the internal structure of the template. This means that if the template changes, so must the view-logic. To decouple this dependency, we need some kind of abstraction.

Luckily it just so happens that there is a very convenient mechanism for that; Element id’s can be used to address central nodes in the markup. They do however have the rather annoying limitation (For this use), that they must be globally unique to the document. A better candidate then, is to use classes (The HTML attribute - I’m not talking of PHP classes) to address elements.

The really nice thing about using classes is that it’s very unobtrusive to the markup. One will have to add classes, but since they would have to go on central elements in the markup, they would be prime candidates for reusing as fix points for CSS rules and for Javascript code. Instead of being superfluous markers in the HTML code, they actively help to write better markup.

That sounds good in theory, so to see how it holds out in reality, I mocked together a small prototype. Even with a very limited API, it has a remarkably good expressiveness:

Simple variable binding

$t = new Domling('<p class="hello"></p>');
$t->capture('hello')->bind("Hello World");
echo $t->render();

<p class="hello">Hello World</p>

Switching a block out

$t = new Domling('<p>Lorem Ipsum</p><p class="message">Hidden message</p>');
$t->capture('message');
echo $t->render();

<p>Lorem Ipsum</p>

Putting it back in

$t = new Domling('<p>Lorem Ipsum</p><p class="message">Hidden message</p>');
$block = $t->capture('message');
$block->bind();
echo $t->render();

<p>Lorem Ipsum</p>
<p class="message">Hidden message</p>

And looping over a block

$t = new Domling('<ul class="links"><li class="link"><a class="anchor" href="#">title</a></li></ul>');
$links = array(
  'Sitepoint' => 'http://www.sitepoint.com',
  'Example' => 'http://www.example.org?foo=bar&ding=dong');
foreach ($links as $title => $link) {
  $t->sequence('link', 'links')->bind(array('anchor:href' => $link, 'anchor' => $title));
}
echo $t->render();

<ul class="links">
<li class="link"><a class="anchor" href="http://www.sitepoint.com">Sitepoint</a></li>
<li class="link"><a class="anchor" href="http://www.example.org?foo=bar&amp;ding=dong">Example</a></li>
</ul>

If you’re curious, you can get the full source code for the above examples from here: http://php.pastebin.com/f76ba8d70

But please mind that this is just a proof-of-concept; There are probably a few quirks that should be ironed out before this could be used in production.

The gold standard solution is to convert everything to utf-8. Since utf-8 covers the entire unicode range, it is capable of representing any character that latin1 can. Unfortunately, that’s a lot easier to do from the outset, than with a big, running application. And even then, there may be third party code and extensions, which assume latin1. I’d much rather continue with latin1 being the default, and only jump through hoops at the few places where I actually need full utf-8 capacity.

So after some thinking, another solution dawned on me. To be fair, hack is probably more descriptive than solution, but nonetheless. The idea goes as follows:

• Use latin1, but serve pages in utf-8, encoding it at output.
• Embed utf-8 strings within latin1, and somehow don’t encode it (But still encode everything else).

Simple, eh?

Latin1 on the inside, utf-8 on the outside.

When rendering HTML pages, it is trivial to capture the output with an output buffer and pipe it through utf8_encode. The page is thus served in utf-8, even though everything internally is latin1. Not much gain in that, since it still restricts us to use the range of characters covered by latin1.
We are actually already doing this, simply to reduce the number of problems for external services communicating with our system. In particular, XmlHttpRequest defaults to utf-8, regardless of the page’s encoding.

In essence, the following snippet exemplifies:

// declare that the output will be in utf-8
header("Content-Type: text/html; charset=utf-8");
// open an output buffer, capturing all output
ob_start('output_handler');
// when the script ends, the buffer is piped through this functions, encoding it from latin1 to utf-8
function output_handler($buffer) {
  return utf8_encode($buffer);
}

Embed utf-8 within latin1.

This is the tricky part. Instead of simply piping the entire buffer through utf8_encode, the string can be parsed so anything between a set of special tags (Eg. [[charset:utf8]] ... [[/charset:utf8]]) is left as-is, while the rest is assumed to be latin1 and encoded with utf8_encode as before. This ensures full backwards compatibility, while allowing real utf-8.

Let’s modify our output-handler from before:

header("Content-Type: text/html; charset=utf-8");
ob_start('output_handler');
function output_handler($buffer) {
  return preg_replace_callback(
    '~\[\[charset:utf8\]\](.*?)\[\[/charset:utf8\]\]~',
    'utf8_decode_first',
    utf8_encode($buffer));
}
function utf8_decode_first($match) {
  return utf8_decode($match[1]);
}

And that’s it. We can now embed full utf-8 strings within our otherwise latin1-encoded application, by wrapping it with [[chaset:utf8]]. To make things a bit more readable, I added a helper function:

function utf8($utf8_encoded_byte_stream) {
  return '[[charset:utf8]]' . $utf8_encoded_byte_stream . '[[/charset:utf8]]';
}

And we can now construct a string as simple as:

echo utf8("blÃ¥bær") . "grød";

To produce the output: blåbærgrød

note: As pointed out by Kore, it would be a problem if the delimiter itself (Eg. [[charset:utf8]]) is part of the data. To remedy this, it would be safer to use a more unique delimiter. You could simply replace charset:utf8 with something that is unlikely to ever happen. It’s still not completely bulletproof, but it’s good enough for most practical uses.

Handling input.

You may or may not know this, but when submitting a form, browsers send back data in the same encoding as the page was served. Since our application is predominantly latin1, we need user-input to be latin1, to keep BC. So all input must be decoded from utf-8 to latin1. This is simple enough; We just have to pipe all user-input ($_GET, $_POST etc.) through utf8_decode. Since we already run with the latin1-on-the-inside-utf-8-on-the-outside scheme, this was already in place in our case.

This does however give a problem when the user needs to submit utf-8, as our users would need when replying to mails. So in these places, we would have to explicitly access the “raw” string, through an alternate mechanism. In our case, we needed to modify our http-request wrapper, but since this is extending the API, there is no BC problems.

With the advent of PHP6, perhaps such hacks won’t be necessary in the future, but for now this gives a working, unobtrusive solution.

Just a short background, Rasmus Lerdorf is the creator of PHP and still continues as a core developer to the PHP project.

PHP frameworks

In his address he choose to highlight PHP frameworks (Drupal was not spared) and how poor they are at performance. Not only are they slow, but their "jack-of-all-trades" attitude leads developers down the wrong path by not using what is best for the job. He continues on by stating that PHP developers really need to think about performance for not only scalability reasons but for green reasons. If programs were more efficient it would cut the number of data centres and would reduce energy needs as a result. In our newly emerging age of energy awareness this does become an important aspect and I am glad that he is raising awareness.

Back to frameworks, he started by discussing a database heavy Twitter mashup that he created. This does a lot of database calls and a lot of behind the scenes work. By hand-tuning it he was able to get on the order of 280 req/sec. By comparison and simple HTML page with nothing but "Hello World" served by Apache is just over 600 req/sec. Okay, stage is set (by the way, this was tested on his local machine).

Hello World

How do PHP frameworks score on the "Hello World" test? No database calls, just the framework being used in its native tongue to output Hello World. The results were not too good, one of the fastest got just over 120 req/sec, the slowest was 8 req/sec. This is a dramatic difference and of course highlights his argument for performance. Where did Drupal score? Right above 50 req/sec. So not the greatest, but he did make the point that Drupal is not really a framework in the traditional sense. It is a web content management system that can be quickly extended.

So, are there any frameworks that don’t suck? Rasmus did mention that he liked CodeIgniter because it is faster, lighter and the least like a framework.

How to make PHP fast

"Well, you can’t" was his quick answer. PHP is simply not fast enough to scale to Yahoo levels. PHP was never meant for those sorts of tasks. "Any script based language is simply not fast enough". To get the speed that is necessary for truly massive web systems you have to use compiled C++ extensions to get true, scaleable architecture. That is what Yahoo does and so do many other PHP heavyweights.

RDF, Semantic Web and the Monkey

RDF in Drupal. Rasmus made a special point of highlighting the importance of embedding structured metadata into the page. RDFa allows you to embed data into your web pages and also lets you create custom vocabularies, or even better, reuse existing vocabularies. Why would you want to do this? Searchmonkey will go out and index this content and open up a rich search API to allow you to do intelligent queries. Well beyond what is possible with traditional search.

Along with rich search you also get enhanced search results. I have blogged about this previously so take a look. It is really cool stuff and I will be discussing it in much more detail over the course of the conference.

Pitching the Semantic Web

What if all Drupal sites had embedded RDFa tags? Well, for one, Yahoo would be very happy. It would play directly into the strengths of Yahoo’s new Semantic Web strategy. They are trying to do interesting things with semantic data but of course they need data — the classic chicken and egg thing.

Rasmus mentioned that Yahoo’s semantic data store can scale to the size of the web so the invitation is open.

The future of Drupal

This is where my focus at Drupalcon is, driving the adoption of semantic technologies within Drupal — I feel that the momentum here will make that a reality. There is a lot of interest, a Semantic Web BoF session was stacked with people with some cool ideas…

More to come.

But a problem I came across several times was the sheer complexity of recursive element conversion — <code> becomes <jsvalue> (or one of a dozen similar elements), <a> becomes <xref> … and that’s all simple enough; but each of these elements might contain the other, or further child elements like <em>, and as we walk through the DOM so the incidence of potential recursion increases, until it gets to the point where my brain explodes.

There’s a limit to how much recursion I can get my head around — or rather — a limit to how much I’m prepared to get my head around before I just go the heck with this, why can’t I mangle it as text with regular expressions!?

Unfortunately there doesn’t seem to be a way with PHP DOM to get the text equivalent of any arbitrary node, but we can do that at the Document or DocumentFragment level; so with a little toying-around I came up with a way to leverage that capability and make it work at the Node level.

So for example, let’s begin with this XML:

<?xml version="1.0" encoding="utf-8"?>
<root id="introduction">
	<div class="section">
		The fundamental data type is <code>Node</code>
	</div>
</root>

We have a reference to its DOM saved to a PHP variable called $xmldom. And we want to parse it so that the <code> element becomes a <jstype>, and the <div class="section"> becomes simply <section>, all without affecting the rest of the document.

Here’s the complete code to do it, which I’ll then talk through stage by stage:

$node = $xmldom->documentElement->firstChild;

$doc = new DOMDocument();
$doc->loadXML('<xmltext/>');
$node = $doc->importNode($node, true);
$doc->documentElement->appendChild($node);
$xmltext = ereg_replace('^.*<xmltext>(.*)<\/xmltext>.*$', '\\1', $doc->saveXML());

$xmltext = ereg_replace('<([\/]?)code>', '<\\1jstype>', $xmltext);
$xmltext = ereg_replace('<([\/]?)div[^>]*>', '<\\1section>', $xmltext);

$node = $xmldom->createDocumentFragment();
$node->appendXML($xmltext);

$xmldom->documentElement->replaceChild($node, $xmldom->documentElement->firstChild);

In the first step we get a reference to the element we want to work with, and save it to $node.

In the second step we create a new document, and use loadXML() to create a placeholder root node (the loadXML method converts text input to XML, and is one of the cornerstones of our process). Next we import the original node into that document, then use saveXML() to convert the whole document to text (the saveXML method converts an XML document to text, and is as critical as loadXML() for what we’re doing here). The text output is parsed using ereg_replace to remove the outer contents of the document (its prolog and root node) so that we’re left with a text equivalent of the original input node.

In the third step we do whatever text-based mangling we need; in this case it’s simple element name conversions, but it could be anything.

In the fourth step we want to convert our parsed text back into XML, and we do this by creating a document fragment, then using appendXML() to load the text and have it converted to XML (the appendXML method does the same thing as loadXML(), but it doesn’t require an entire document to be created).

Finally, in the fifth step we merge the processed XML back into our original document. The document fragment has the original document as its owner, so we can simply use the replaceChild method to replace the original node and its children with the processed version. (Whenever a document fragment is added to a document, only its children are actually added, the document fragment itself is discarded; DocumentFragment is a virtual construct and never actually appears in a document.)

Both the first and the final step are arbitrary — we could work with an entire document, or just a single node, and edit our referencing and merging statements accordingly. Or we could build a method from the inner steps, which accepts $node as an argument (and maybe an array of replacement expressions), and returns the processed node at the end:

function mangleXML($node)
{
	...
	
	return $node;
}

While we’re at it, Steph Fox have dutifully been writing up summaries of php-internals discussions on a weekly basis since the beginning of time. If you just want to get the headlines, it’s an informative read.

Have a nice summer.

PHP is designed for the web. You could plug vanilla Ruby or Python into a web server and get up and running pretty quickly. But, at least at a basic level, you’d want a framework to deal with common issues of web development. In PHP, you just get started. PHP and Apache work out request data, output handling and more, right out of the box. (PHP also masters deployment.) David Heinemeier Hanson, the creator of the Ruby on Rails framework, calls this the immediacy of PHP.

Now, consider the “average” PHP frameworks. They help you handle request data, manage your output, control app flow - essentially, extending PHP’s inbuilt functionality. They are, therefore, PHP frameworks on the PHP framework. PHP provides a vast array (pardon the pun) of functionality out of the box. But when you want to do things your way, it gets out of the way, and this is really important when building anything beyond a simple database frontend.

How many PHP applications in wide distribution are built on a third-party framework? MediaWiki? No framework here. Wordpress? Not here either. Drupal? You get the idea. Each of these applications have their own framework, inasfar that the developers built a structure for their code that suited what they were trying to create. These three, and the countless others, clearly did something right - MediaWiki even powers one of the world’s top 10 websites. And when building these “frameworks”, PHP helped them along the way.

Sure, Cake, Symfony, CI - they all help you build PHP applications. But unlike a Ruby framework or a Python framework, coding is perfectly tolerable without them. Of course, most developers tend to create their own framework as they go along - I call this PHP’s DIY framework mentality, where you build the last level in your stack, and by extension you know exactly what’s going on under the hood.

This comes back to the oft-cited “best tool for the job” argument - but by being a “half framework” of sorts, PHP simply helps you within a web context. I’m sure Rails is great for countless applications; Ruby syntax helps a little too. But beyond the basics, the language becomes increasingly irrelevant, and a framework will force you to build your app according to design decisions made by the original developers. On the other hand, PHP allows you to quickly put together your application the way you want, helping you with the web-based aspect, and without having to break the language/framework to achieve your goals. Essentially, PHP is the web layer without the framework baggage.

Twitter recently had some downtime that could be attributed to its use of Ruby on Rails. Now, there’s nothing wrong with Ruby, or Rails. But Twitter is a messaging system, RoR is an application framework. Could Rails be worked around to suit Twitter? Maybe. Could Twitter have avoided these problems if they’d used PHP? Probably. Twitter’s developers have noted they weren’t quite expecting the site to be so succesful. If they had built it in PHP, they would probably have encountered other (similar) problems earlier on, rewritten the entire app while it was still feasible, and built a powerful system that could scale just fine (likely with the messaging platform in C). Using PHP could have helped, not as a language with syntax and libraries as such, but as a web development platform that gives developers the freedom to architect their systems as they want. (They could also have tried Erlang.)

So the next time you’re on the lookout for a PHP framework to build your killer app on, consider using the best framework of them all: PHP. It will give you the freedom to achieve what you want, how you want, with results. A quick hack? Check the manual, it could be a one-liner. A massive distributed messaging platform? Full steam ahead, build it your way. For everything in between, there’s a multitude of options, but if you have the time, PHP is all the framework you need.

When it comes to optimizing PHP for performance, there’s no end of resources available, and no end of conflicting opinions either. Everyone seems to have their own approach to writing “fast” PHP code; using single quotes, avoiding require_once() and using isset() before is_array() are some of the most common. But with reliable benchmarks thin on the ground, how do we know if any of these techniques - often touted as “performance best practices” - actually deliver benefits? Chris Vincent’s new PHP benchmark suite at PHPBench.com aims to “set the record straight” on PHP performance techniques, with a simple, comprehensive view of how various approaches actually stack up.

The benchmark suite covers all the usual bases, taking a simple task — like iterating over an array — and speed testing almost every possible way to achieve it. Most importantly, however, Chris takes raw numbers out of the spotlight and instead focuses on how the options compare with each other. Each test takes the fastest technique as the base value for execution time; all the other options are measured as percentages in relation to this. For example, foreach($aHash as $val) has script execution time of 558% compared to while(list($key) = each($aHash)) $tmp[] = $aHash[$key] with 100%.

The test scores are also generated live; refreshing the page will produce a slightly different set of results. Chris uses the header of the relatively uncomplicated results page to recommend refreshing a few times, just to ensure consistency and to avoid a one-off impact on any particular test. Personally, I’d have preferred the tests be carried out in a controlled environment and regenerated every time a new test is added; anomalies don’t help anyone and live benchmarking offers little real benefit besides operational simplicity. The code for each test is supplied for transparency.

His current set of tests are very comprehensive; no less than 13 tests compared the performance of various echo and print calls, with enough variety to check for any usage scenario. He’s also accepting suggestions for new tests. Most importantly, however, many of his tests help identify the value of best practices. For example, PHP is often criticised for the vague results of == comparisons; the control structures tests show us that not only is === safer, it also takes about 2/3 as long to execute.

While most of the tests show trivial performance differences, there are some interesting results. For example, iterating over an array and modifying each element is 100 times as fast using while(list($key) = each($aHash)) than a simple foreach ($aHash as $key=>$val), while array_keys() is about 20 times slower than while(list($key,$val) = each($aHash));.

The next step, of course, would be to download the test suite to your local machine or server and run the tests yourself, to see how the factors of your production environment affect the results; Chris aims to make this possible in the near future. Many of the techniques listed are clearly going to be either memory-efficient or CPU cycle efficient, and the limits of your infrastructure will determine which way you want to go before scaling out. Nevertheless, managing bottlenecks in your code can really help you get the most out of your servers — after all, if you can achieve something 100 times as fast, why not? — and PHPBench.com could become the definitive reference on PHP performance.

Update: Many commenters have noted issues with the usefulness and reliability of the tests. It’s important to consider Chris’ intentions while creating the site, as he’s described in the comments. With all the “use this syntax because it’s slightly faster” posts, PHPBench.com was built to see if there is any real material benefit to using a particular syntax; most of the tests show that there clearly isn’t. I’ve done a few tests of my own and seen similar results, but if something looks amiss, feel free to point it out to Chris. The site is not trying to identify immaterial performance benefits from e.g. single quotes vs. double quotes. Moving further, PHP Bench could be used to measure algorithm performance and other more intensive procedures; for now, the basic syntax tests simply reflect the potential of the system. Hopefully this clears things up.

It really begun at the last Copenhagen php-meetup; Joakim Nygård and Jacob Oettinger made a presentation of their project, WebCacheGrind. I casually mentioned something about having played with the dbgp-protocol (The debugging part of Xdebug) and that it ought to be simple enough to write a fontend for it. That prompted some snickering from the back row. Apparently some guys had this rule at their workingplace, that whomever said that something ought to be easy to do, had to do so himself. Not an unreasonable rule, I suppose. Obviously, I couldn’t let that go unattended, so I gave it a shot.

Spectator is a XUL application, which should make it cross platform. I have tinkered a bit with XUL before, but not a full application. If you’re wondering what XUL is, it’s the GUI toolkit, in which the frontends for Firefox and Thunderbird are written. It’s a markup language — much like HTML, which can be scripted with Javascript. This makes it very easy to work with. The only problem seems to be a rather lacking documentation, but a bit of detective work got me through that.

So what can spectator do? Mind that this is a first version and I really just meant it as a proof of concept. I think I got a bit further than that, but it probably still has a few bugs. Still, with the current version, you can step through a program, set breakpoints and inspect the stack. Really all you would expect from a debugger.

Of course, as some of you might point out, there are already other implementations available. Most notably Komodo, which is also implemented with XUL. However, these implementations are proprietary, and are integrated with an IDE, that you may not want to use. Spectator is an open source alternative and is IDE/editor agnostic.

Tracers and error handlers

Both of these functions produce a rather crude output though, so naturally people have written wrappers around them to remedy this. I think Harry’s pretty bluescreen was one of the first dedicated libraries I’ve seen. Xdebug spouts a similar output on error, although arguably not as pretty. Or blue.

What bluescreen is for debug_backtrace, krumo is for var_dump. Recently, FirePHP — building on Firebug — does a similar thing. FirePHP uses HTTP-headers to send data from server to client, which turns out to be very handy when dealing with non-HTML output (Eg. Ajax stuff). Because it builds on Firebug, it only works on Firefox, and in particular only on Firefox 2 (Another reason for Ubuntu-users to downgrade from Firefox 3).

Frameworks

Apart for these general general tracing tools, a couple of frameworks have their own, more or less specific, tools. Symfony’s Debug Toolbar is probably the most impressive (And in contrast, Zend Framework the least), even providing information about database-queries, which is very helpful for profiling.

Another framework-specific tool, which I’m quite impressed by, is the Theme developer module. It’s advertised as “Firebug for Drupal theming”, which is fairly descriptive. In case you haven’t used Drupal, it has a complex theming system for rendering pages and this tool makes it a lot easier to figure out which part is doing what. Even if you don’t intend on using Drupal, it’s fascinating to see how well polished it looks.

I think that most frameworks with an integrated presentation layer, could benefit hugely from something similar, although the specifics would obviously vary. One of my own projects, Konstrukt, has a tool for displaying debug-information about which controllers renders in which order. This can be helpful, because a given page will often have several controllers working in concert to produce the final response.

Another take on this, is Cake PHP’s debug messages. This extension adds very specific and descriptive error messages in various places, which almost works out like a tutorial for new users; Seems like a good idea.

Webgrind

I already mentioned Xdebug, which is indispensable for profiling PHP applications. Last week, Webgrind had its first released. It’s a HTML-based frontend for displaying profiling output, generated by Xdebug. There are already tools for the purpose; If you’re on Windows, WinCacheGrind and for Linux-based systems, kCacheGrind. However, I can see a few good cases for Webgrind;

First of all, a zero-install client is a bit easier to reach out for. For Mac users, it’s also the only option. The featureset is quite limited, but this turns out to be somewhat a benefit. kCacheGrind can be quite intimidating and for the purpose of profiling, Webgrind’s features seems fairly adequate.
The most important though, is that the logfile generated by Xdebug (Which is the data-format for the various grind’s) tend to get rather huge. Naturally, this makes it awkward to have server and client on separate machines — This is not a problem for Webgrind, since it runs at the server side.

Like may SitePoint readers, I cut my teeth on PHP. I’ve become very comfortable with it over the years, warts and all. PHP continues to be a dependable choice, but PHP hasn’t changed a whole lot lately. Meanwhile, the kinds of applications I’ve been working on have been growing dramatically in both size and complexity.

Python has a lot in common with PHP: it’s a dynamically typed, open source scripting language with excellent documentation and a thriving community around it. Both languages are also a little quirky when it comes to their handling of Unicode text.

Unlike PHP, Python wasn’t originally designed as a language for Web development—it’s a general programming language that just happens to have some excellent libraries and frameworks for building web sites, like Django. This may sound like an argument against Python, but it turns out that when you start writing bigger web applications, most of your code has nothing to do with HTML, and PHP’s HTML-friendly features just seem to get in the way.

Enough Hand-waving! What’s The Code Like?

Let’s look at some of the neat features of Python code.

The most distinguishing feature of Python code is the lack of braces or other delimiters around code blocks. Instead, Python uses the indenting of your code to indicate blocks:

print "Let's count to ten!"
for i in range(10):
  number = i + 1
  print number
print "All done!"

The above code includes a for loop that will run ten times. The two lines following the for statement are indented to indicate they’re within the for loop. The last line isn’t indented, so Python knows the for loop is finished.

At first it feels frighteningly fragile to trust indentation to describe the structure of your code; but once you get used to it, you’ll notice that your code looks less cluttered. Even better, you’ll find it easier to read Python code written by others, because developers are forced to indent their code neatly and consistently.

Python has a number of convenient, little features that make common tasks less cumbersome than in other languages. Take multiple assignment, for example, which lets you avoid creating temporary variables:

a = 1
b = 2
print a, b     # prints '1 2'
a, b = b, a+b
print a, b     # prints '2 3'

Python also has a number of slick features for dealing with what it calls sequences. These let you split and combine lists (the equivalent of PHP arrays) and text strings using simple, consistent syntax, instead of having to remember obscure function names for each.

Python’s list comprehensions let you quickly build complex lists out of simple lists with a minimum of code. They’re a little hard to understand at first glance, but they quickly become indispensable:

me = 'Kevin Yank'
range(5)                                 # [0, 1, 2, 3, 4]
[me[x] for x in range(5)]                # ['K', 'e', 'v', 'i', 'n']
[x for x in range(10) if x % 2 == 0]     # [0, 2, 4, 6, 8]
[me[x] for x in range(10) if x % 2 == 0] # ['K', 'v', 'n', 'Y', 'n']

But all that syntactic sugar aside, the biggest feature of Python that I appreciate after years of coding PHP is its sensible system of modules and packages for organizing code into multiple files. In PHP, when one script includes (or requires) another script, it runs the risk of having its own variable, function, and class names clobbered by the script that it is including.

Python automatically sets up a separate namespace for each file (called a module) that your program imports, so that naming conflicts are naturally avoided. This frees you up to choose shorter, more natural names (especially for classes in big projects), while at the same time forcing you to give more thought to the structure of your code.

Where to Begin?

There is little sense in learning a new language unless you have a reason to use it. For the past couple of years, that reason for many web developers has been Django. The best place to start, therefore, is probably SitePoint’s Django Djumpstart article.

More recently, a lot of developers are taking renewed interest in Python because it is the development language for Google App Engine. It’s worth having a look at App Engine before diving into Python.

Speaking of diving into Python, Mark Pilgrim’s book Dive Into Python is available to read online for free, and is a great way to learn the language from scratch. If you’re after something with more depth and detail, the official Python Tutorial is a rewarding read, if a bit dry. It’s also significantly more up to date.