As I was curious, I today tested whether you can use a dash in a file name with Python — or, more specifically, if you can use that file as a module afterwards. You cannot. So don’t name your files with dashes.

(This might be in a manual somewhere, but I hadn’t seen it explicitly mentioned. Maybe it’s just common sense since you can’t name your variables that way either, I don’t know)

I don’t mind Python’s indenting. Sure, it took a little time to get used to it, coming from PHP with all its braces. But it wasn’t really hard.

The only problem I see with its indenting, is the fact that it’s variable. You can use a single space, two spaces, three spaces, […] Heck, you can use 32 spaces or even tabs. Flexibility is often good, but this introduces a problem, which has been touched upon a lot by others as well: Different programmers end up with different tab indexes, making their coding conventions non-interoperable.

To make matters worse, Python treats a tab as an 8 space indent. So the following could happen: one programmer uses tabs as indents, has them shown as 4 spaces, and hacks away happily. Then someone else takes a look at the code in their editor. He might be using an 8 space indent, and so there should be no problems. He edits the code a bit, then sends it back to number one. He then gets mighty confused — why is there all of a sudden a double indent there?

You see how this can scale and get out of control, don’t you?

So what do I propose, in order to fix this? I see two solutions, the one preferable, the other one realistic:

1. Add one standard way of indenting. This should go well with the There’s Only One Way to Do It-philosophy, and should stop all these problems. I could easily settle on 2 spaces, 8 spaces or tabs, just as long as there was this single way. This won’t happen, however. There’s too much code out there, with different indents.
2. A conventional way of commenting the chosen indent. There is already conventions used for commenting the character set among other things, and this should just be one more line to add to the template. # -*- indent: 2 -*- or # -*- indent: tab -*- should do the trick. If this convention catches on, in time editors might even learn to read this, and adjusting the indent to this value. That would be great.

These are my suggestions. I hope someone influential in the Python community sees this, and agrees with me. We need to sort this out, and this could be a way of doing this.

Where you live, should not decide
Whether you live or whether you die

In my post about web.py I touched upon the fact that I don’t like web.py’s way of defining URL’s, that I find it too loose. Well, it’s a minor problem, but rather trivial to solve, so I did. As quoted in the original post, there is a bit more typing, but I personally prefer this solution. (To be fair, the example I gave in the original post can be applied to this code as well, but I’d say this makes it a tiny bit more readable):

def webpyurl(_tuple):
    """
    Map a structured tuple to a url that web.py will accept.

    Turns a tuple of the format
    (
        ('a', 'b'),
        ('c', 'd')
    )
    into
    (
        'a', 'b',
        'c', 'd'
    )

    Rather simple, but can make a huge difference in readability.

    @require enhancedappend()
    """

    thislist = []

    for (a,b) in _tuple:
        enhancedappend(thislist, a, b)

    return tuple(thislist)

def enhancedappend(_list, *appends):
    """
    list.append only takes 1 argument, this allows for more to be added
    """

    for append in appends:
        _list.append(append)

This code is also available on pyhacker.

Keep you doped with religion and sex and TV,
And you think you’re so clever and classless and free,
But you’re still fucking peasants as far as I can see.

What is in us that turns a deaf ear to the cries of human suffering?

Who controls the past now, controls the future.
Who controls the present now, controls the past.
Who controls the past now, controls the future.
Who controls the present now?

Got to be good looking, because he’s so hard to see.