Why I Like

Why I like Python

(I changed the title from “PHP vs. Python” to “Why I like Python” after the fact. Just seemed more fitting)

Okay, I have a confession to make: this is less “PHP vs. Python” and more “coming from a PHP background, this is why I like Python.” Only, that title was too long. Note well, though… this is not meant to be an unbiased and/or impartial comparison by any means. This is my personal opinion, and should be taken as such. Anyway.

I’ve been firmly entrenched in the PHP world since, oh I don’t know, 2004… it was the language I was using when I really learned about software development, and I’ve been pretty faithful to it for a long time. The large base of information and support available, and the fact that I do primarily web development may have had something to do with it as well, but who’s counting? Recently, though, I’ve been getting kind of bored with PHP as a language. Sure, it’s sort of carved itself a niche as the de facto language of the web, but even as a web developer, there are projects that I would love to tackle that are just… beyond the scope of the language. So, I’ve been looking elsewhere. Python was one of my first stops (the very first was Ruby, but that’s a different post).

The thing that first attracted me to Python was that its syntax reads very much like pseudocode. A Python script reads like I think when I’m writing code. That, combined with significant whitespace in place of braces and semicolons and what have you (it’s really not that big of a deal to get used to, trust me), really makes it easy for me to grasp the fundamentals of what’s going on with a piece of code.

Also, you can call this petty if you want, but I really do much prefer the dot operator to the arrow. Doesn’t foo_object.bar_method() just read so much more clearly than $fooObject->barMethod()? Yeah, you know that’s right.

Another thing that I approve of wholeheartedly are class property attributes. If you don’t know about these, they’re awesome. Coming from a language influenced by C++ and Java, you know up front that if you ever want to have any kind of control over the getting or setting of a property, you’d better make your class properties protected from the very start and use getter and setter methods. With Python? Not necessary. You can start out with plain old properties, modified directly. If, at some point in the future, you decide that you need to wrap property access with additional logic, you can just add getters and setters to the property. Check it out (this is a modified example from the docs I just linked):

In both examples, you’d use the class the exact same way: some_c.x = 'whatever'. But in the second example, you can wrap the call with whatever additional logic you’d like. And, if you decide to switch from the first example to the second, your API doesn’t have to change at all. That’s powerful.

Oh yeah, and Monty Python references. Awesome, right?

I mentioned a few paragraphs ago that PHP has carved itself a niche in the web market. And of course it has: that’s what it was built to do. I often hear the argument made that while Python or Ruby or Node are “better” or “more powerful” languages (imagine air quotes around those, because I think that subscribing to hype is stupid), it’s much easier to get a website online with PHP than with those other languages.

Let me address that for a second: PHP is built to put content on the web, yes. Using just the core language libraries, then yes, it’s probably easier to get that website about your cat Captain Biggles online using PHP. Erm, the website is online using PHP, that is. Not the cat. But I digress.

But here’s the thing: you don’t have to use just the core language libraries. People much smarter than you or I have already come up with a solution to that problem. It’s called Django, or Pylons or web.py or whatever. Web frameworks. Written in Python. Check ’em out. Then you can stop worrying about how hard it is to get content online with a given language and start worrying about creating content that people actually give a rat’s end about.

I reiterate: everything that I’ve mentioned is simply a matter of personal taste. Maybe you hate Monty Python references (heathen). Or maybe you absolutely can’t get past the significant whitespace of the language (this Stack Overflow question on the subject makes my blood boil). That’s fine. Write your own blog post extolling the virtues of your own chosen language. But I think that way too often, we listen to the opinion that the tech in-crowd kids are feeding us and follow like good little sheeple without bothering to check our own facts.

Don’t do that.

3 thoughts on “Why I like Python

  1. What’s the difference between what you did and what I would do in C++ or Java?.

    All you’ve done is rename your variable to _x and create a getter/setter with the old name so you don’t have to refactor anything, which you can do in any OO language.

    Your description of what you can do is not unique to Python. I’m much more interested in why you would do it that way. In other words, what is it about Python that would make you rethink the “Best Practices” or whatever coding standard your industry has adopted for Java, C++, etc, with respect to wrapping member variables in getters/setters?

    1. It would appear that I’m wrong about Java and C++ being able to replace x with a getter/setter pair without being able to refactor.
      But there are other languages which behave this way (.NET languages, and ActionScript to name a few).
      Even though this is “syntactic sugar”, this is a good feature of any modern OO language. I’m glad Python included this!

    2. All you’ve done is rename your variable to _x and create a getter/setter with the old name so you don’t have to refactor anything, which you can do in any OO language.

      I have to disagree here. You can’t do it in PHP or, unless I’m mistaken, Java. In both languages, renaming x to _x and creating a getter/setter would then require you to use this.x() instead of the original this.x; definitely not the same thing as far as API usage is concerned. Edit: Looks like you came to the same conclusion I did. And apparently I’ve been under a rock for too long, because I’ve never heard of this feature before, but I’m glad it exists.

      As far as why I would use property attributes, I have a strong distaste for creating two methods for every property that do nothing but the update the property or return it, against the possibility that someday I might need additional logic. It’s just needless additional complexity in something like 80% of cases.

Leave a Reply