zephyrfalcon.org :: labs :: Python beginner's mistakes

Every Python programmer had to learn the language at one time, and started out as a beginner. Beginners make mistakes. This article highlights a few common mistakes, including some I made myself.

Beginner's mistakes are not Python's fault, nor the beginner's. They're merely a result of misunderstanding the language. However, there is a difference between misunderstanding (often subtle) language features, vs misunderstanding the language as a whole, and what can (and cannot) be done with it. The pitfalls article focused on the former; this article deals with the latter.

To put it another way, the mistakes in this article are often cases of "the wrong tool for the job", rather than coding errors or sneaky language traps.

Mistake 1: trying to do low-level operations

Python is sometimes described as a VHLL, a Very High-Level Language. As such, it is naturally suited for high-level tasks, like generating or parsing HTML pages, scripting a game engine, or writing web frameworks, to name a few examples. It is not so suitable for tasks typically done by low-level languages, like writing device drivers, or tasks where performance is critical, like rendering of 3D graphics, or serious number-crunching.

This doesn't mean that it isn't possible to do these things with Python; but it's probably just not the right language for these jobs. One way to work around this is to write the low-level code in C, then have Python call it.

Mistake 2: writing "language X" code in Python

This is a mistake that is almost unavoidable. You come from, say, Pascal, and try your hand at Python. The first code you write will probably look like Pascal with a Python syntax. You are writing Pascal code in Python.

Some notorious symptoms of "language X" code, and the languages that may cause them:

You're really paranoid about data hiding (some would call this "encapsulation"), and/or write getters and setters for all object attributes, no matter whether they add special rules or not. (Java, C++, Delphi)

You overuse properties (one of the shiny new features in Python 2.2). (Java, Delphi, maybe Visual Basic, C++?)

You write a program that is one long list of statements, rather than using functions or classes. (old Basic)

You use functions that pass a data structure around, rather than using objects. (Pascal, C)

You heavily rely on recursion, where iteration would be more appropriate. (Lisp, Scheme, other functional languages)

You are writing too many slightly-different objects, where a few objects would suffice. (Java, C++, other statically-typed OO languages)
(It is my experience that in Python you can often get away with writing fewer classes, using Python's dynamic features to deal with differences that would require a separate class in less flexible languages.)

You are chaining many function/method calls, making code less readable. (Lisp, Scheme, maybe Perl?)

You write a lot of functions returning functions returning functions (...etc...), manipulating namespaces enclosed by these functions, where objects would be more appropriate. (Lisp, Scheme, other functional languages)

You use bytecodehacks to implement a "come from" statement. (Intercal)

The point here is not to slam the language that you're used to (although that is always fun ;-). The point is to emphasize that good "language X" code and code practices cannot always be directly translated to Python.

Mistake 3: trying to make Python fit the environment that you're used to

This one requires some clarification. When I learned Python, back in 1996-1997, I was used to using Turbo Pascal, in DOS. I often wrote programs that used "text graphics" consisting of characters (ASCII 0-255), in 16 colors, (ab)using the VGA card's capabilities. I was used to mixing code with inline assembler, and DOS interrupt calls, and talking to hardware directly (sound, video card, CD-ROM).

It is obvious that Python was not the ideal language for these tasks in this environment. Yet I was interested in the language and wanted to use it. So, I tried to make the square peg fit in the round hole. Python couldn't do the things I wanted (or rather, considered "normal" or even "necessary" at the time), so I experimented. Drawing the text graphics using an ANSI driver, for example (very slow). Eventually I rolled my own Python, compiled with DJGPP (some readers might remember Python-DX; old executables are still available in the download area). I added modules for low-level DOS calls, interrupts, text graphics, etc.

The problem with making your own version is, that hardly anybody else will use your (incompatible) flavor of Python. It's not necessarily wrong; but these days, there are better ways of extending Python, e.g. with libraries that can be loaded dynamically. Alas, this wasn't possible back in the DOS days (or if it was, I didn't know how :-).

The lesson here is, that trying to make Python fit your existing environment, may or may not work. If it doesn't, Python probably isn't to blame. Either way, it's not the ideal way to get started.

Mistake 4: "the obvious way" in language X, vs "the Python way"

If you come from another language, then you often think of certain ways to do things as "obvious". For example, in Java, C, Pascal, etc, it is perfectly normal to loop over a string, in order to copy it or modify it. What could be more natural? You may also be used to concatenating strings with lots of s1 = s1 + s2 statements, and your language of choice does this efficiently and fast. Or maybe you're used to creating your own linked lists or binary trees.

Surprise: these constructs do not necessarily work well in Python. Yes, you can loop over a string, concatenate the same way, and create linked lists. And these ways of doing it are not uncommon, especially the first two. But before doing like this, maybe it's good to check if there isn't a better way. For example:

Looping over strings is perfectly fine, but if you are looking for a certain character, or a substring, or if you are doing a conversion of some sort (stripping whitespace, upper/lowercase), then take a look at the string methods (or the string module) first.

Concatenating strings using s1 = s1 + s2 is fine as well, and not a problem if you're just doing this once or twice or so. But if you are doing this operation a lot (e.g. in a loop), and need good performance, then string.join is a better choice. (See pitfall #8.)

Creating your own linked list is usually not necessarily, unless you're doing something special. Chances are that Python's built-in list type will do what you want, and more. It's also most likely a lot faster than your homebrewn solution.

Some advice

Python is easy to learn, but it takes a while before you really grasp the implications of using a dynamic and very high level language. Dynamic languages allow for a different type of software design. People usually don't realize this immediately.

So, use Python's strengths, rather than coding around them for irrational reasons, or using the language in situations where its benefits don't really shine. To name a few of these strengths:

highly dynamic objects (add attributes, methods on the fly)
"signature-based" polymorphism, sometimes called "duck typing" ("if it walks like a duck and quacks like a duck, it might as well be a duck" :-)
powerful built-in objects; try lists and dicts first before reinventing the wheel

Also, no matter how much I like Python, remember that it simply might not be the right language for the specific task you have in mind. There are still areas where other languages outshine Python. However, the number of areas where Python wouldn't be appropriate, has gradually been declining. Vanilla Python might not be enough, but Python + extension packages might.