Minority Opinions

Not everyone can be mainstream, after all.

Five reasons to love Python

with 2 comments

I’ve been debating language preferences with a Visual C++ user lately, and it been interesting to see things through the perspective of someone who won’t pick up my favorite programming language, but not for the standard knee-jerk reason. I’ve tried several languages, and have found the one that works best for me, but it might not be for everyone. Intriguingly, my sparring partner’s reasons for avoiding Python mirror some of my favorite features.

These aren’t all of Python’s good points, by any means, but provide a nice overview.

Clean Syntax

One of the first things people notice about Python, particularly those familiar with relatives of C, is the indentation-based block formatting. For some reason, it’s a polarizing feature: Some love it, others hate it. I’m a fan of clean, easily-readable, properly-indented code in any language, so it doesn’t mean any lost time for me. The benefit, in contrast, is huge: I don’t get annoyed by someone else’s poor choice of brace style, nor with their lack of indentation for key constructs.

Other ways Python code is clean:

  • No redundant type declarations.
  • No sigils on variables. Contrast Perl’s type-defining sigils in particular, which gave me quite some grief when I picked it up after a period of disuse.
  • No new operator, making the difference between a constructor and a factory function irrelevant.
  • No extra parens around if and while conditions.
  • A for loop that simply and effectively iterates over sequences, combined with simple functions for the cases where you really do want an index or other numeric step.
  • Spelled-out logical operators, with no symbol-based equivalent for confusion.
  • A consistent set of operators that can be overridden for effective use by several types.
  • The ability to directly take an index of an arbitrary expression, including a function call, with neither a cast nor a temporary variable.
  • Sequence unpacking on assignment, particularly for returning multiple values from a function call.
  • Strings that let me decide to ignore backslash escapes, particularly for regular expressions. On a related note, a regular expression library that doesn’t require me to supply my own slashes.

Memory Management

Somewhere, in the back of my head, I understand the difference between the stack and the heap, but I like not having to worry about it. I like being able to pass things around without dealing with where they need to be deallocated.  Strings, buffers, and lists just take care of themselves, without allowing memory-corrupting overflows.  I really enjoy the collapsing of pass-by-value and pass-by-reference into pass-by-sharing and multi-value returns.

The ability to release other resources (open files, open sockets, held locks) when they go out of scope is also nice, but I would prefer not to rely on it. That makes the new with block theoretically attractive, though I haven’t actually used it much.

Safe, Dynamic Typing

I like being able to pass values around without having to worry about their types all the time. A value just is what it is, and can’t be treated like something else without explicitly creating a new object from it. When I really need to, I can ask a value what type it is, and act accordingly. Mostly, however, I can simply use values as if they’re sequences, or strings, or numbers, or whatever I happen to need, and rely on the caller to provide something appropriate.

I like the freedom to change an underlying representation without fiddling with all of the places it gets used. I like being able to use values from library functions without worrying about their types, as long as they act as documented.  Most of all, I enjoy having convenient syntax for using sequences or callables as values, without worrying about exactly what they are.

Function Parameter Specifications

Python functions combine the best parts of variable argument lists, default parameter values, and named parameters. As a function writer, you can choose to allow any number of positional arguments, any number of named arguments, both, or neither, in addition to the parameters you name. You can give your parameters default values, or you can make them required. The new ability to define keyword-only parameters is simply gravy.

As a function user, you can specify values for named parameters in any order; this is particularly useful for specifying one optional argument without touching any defaults that may come before it. You can also expand sequences or dicts straight into argument lists, without needing a temporary representation. Best of all, you can ask the function itself about the parameters it expects, and it will tell you. (Most of the time, anyway. Certain built-in functions are poorly documented in this regard.)


I have used Python for quick arithmetic, small proof-of-concept scripts, simple problem solving, basic data mining and parsing, minor web applications, and full-blown server implementations. It works equally well at all levels, allowing me to work at the proper level of abstraction. For the most part, it has libraries to help with the hard bits; often, the hardest part of a problem is choosing which of several similar libraries to use. Finally, it doesn’t make me wait forever while it decides whether to compile, even on the largest piles of code.


Written by eswald

21 Mar 2011 at 10:16 pm

Posted in Python

2 Responses

Subscribe to comments with RSS.

  1. Your friend is crazy. Now if you have a Rubyist friend, that’s a debate I’d be interested in.

    Daniel Reeves

    22 Mar 2011 at 2:37 pm

    • I’ve tried Ruby. It has no obvious advantages over Python other than anonymous blocks. However, the ugly syntax, a few dubious design choices, and a culture of monkey patching are enough to dissuade me. I’ve used Perl, though, so I’m sure I could have gotten into it if I hadn’t already found the perfect language.


      23 Mar 2011 at 2:56 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s