Enjoy, you’re doing it wrong!


Mixing tabs and spaces in Python
March 24, 2009, 7:00 am
Filed under: Uncategorized

You’re doing it wrong.

Actually, even if you generalize the problem to Mixing tabs and spaces in code, you’re still doing it wrong. When coding a program, a file in a project, something, you should choose an indentation style, n spaces, or a tabs, and stick to it:

The issue here is editor-dependent. Suppose that a coder A creates a program where tabs and spaces are mixed. Because A is not doing everything wrong, he tries to have a properly indented code, and indents identically each code line within a same code block. But the way a tabulation looks depends on the text editor of A: if, let’s say, his editor renders a tab as 4 spaces, then he will insert multiples of 4 spaces a bit everywhere in his code that will be fulfilling the same indenting role as a tabulation.

And here comes coder B, who uses an editor which renders tabs as 8 spaces… The code will look broken, you get the picture.

But of course in Python where indentation is a language requirement, it’s even worse. The code not only looks broken, odds are that it is broken. Better, if you’re very lucky, the syntax will still be correct, never raising any Indentation Error at any point in the code, but your control flow will be silently broken, functions returning too early, breaking out of loops too early, etc… Stealthy borked code. Sounds nice, right?

And today looking at the last code commits you notice that yet again, while you were sleeping, some contributor inserted tabs in your project that uses a 4-spaces indenting convention. Damn hippie.

Well, it’s okay, you got up early today, and you’re feeling smart, as usual. You’re going to fix this, to teach that dude a lesson. You quickly hack a small bash one liner that will replace tabs by 4 spaces:

for file in $(grep -Rl [[:cntrl:]] . | grep "\.py$"); do sed -i 's/^\t/ /g' $file; done

You run it in your project base repertory, hint at the changes — it works, I’m too good! — and commit/push them, and get back to work. Perfect, right?

Well, days later, when tens of commits piled up, people come to you complaining that this and that feature stopped working. You look at the commits, you see nothing wrong. Naturally, you assume that those punks got the command line arguments wrong, and tell them to try again.

But nothing does it. There’s a pretty major regression. After a few minutes you understand that this is the well known Stealthy code phenomenum, and take a closer look at the indentations fixes you made a few days ago. And of course you did it wrong. Assuming that a tab should be replaced by 4 spaces because your project uses a 4-space convention was a completely wrong supposition. PUNK!

And now you’re stuck doing painful merges to try to include the recent commits while fixing correctly the indentation issues. If you learned your lesson well — but chances are that you did not — you might be considering adding a python -tt à la CruiseControl dictatorial test to automatically reject any incoming patch containing tabs.



Python.h
March 19, 2009, 6:54 am
Filed under: Uncategorized

ProjectXXX/yyy.c:nn:cc: error: Python.h: No such file or directory

Don’t even start. The source you’re compiling is probably just fine. You’re doing it wrong.

You probably have python installed, but you do miss the development version and its corresponding headers. Look for python-dev or something, but don’t even think about complaining to ProjectXXX’ devs.



Well, if you’re reading this…
March 18, 2009, 7:24 am
Filed under: Uncategorized

You’re probably doing it wrong. Sorry.

Header from dommend, cc-by-nc-sa.