Wandering Thoughts archives

Why I like Python more than Perl

My attempts to write a general 'why I like Python' entry to answer a recent comment have floundered completely. However, part of the answer is in the reasons why I like Python more than Perl, and I came up with a summary of that back when I started programming in Python (and still had a copy of it, once I could find it).

The three problems I have with Perl that Python deals with are:

1. an unstructured namespace, which means that any time I want to do something I get to hunt through a listing of six zillion routines, most of them irrelevant.
2. limited data structures unless I get a chainsaw and do pointers (I get 'scalars' and 'containers of scalars' and after that have to resort to more or less explicit use of references).
3. a profusion of namespaces, with confusing operators and distinctions and passing them around and rules for doing things with them and and and.

(Disclaimer: tastes differ. I don't expect everyone to have my reactions to Perl, and there are certainly appealing aspects of Perl (including CPAN).)

Using Python to test system behavior

One of the things I like about the Python interpreter is that it is just about right for doing little system behavior tests, like how various systems handled a TCP port binding issue. This is because Python is low level enough to be relatively close to the actual system, so you can be pretty sure that what you're seeing isn't Python-specific behavior, while at the same time being high level enough that you can do the tests in a couple of lines.

Strictly speaking you don't need an interpreter for this, just a language at the right level, but having an interpreter avoids the whole drag of editing and running and re-editing and re-running and so on.

(And theoretically you can write this stuff directly in C, but I'm certainly not familiar enough with things like the C socket API that I can toss off test programs for this in ten minutes or less. In Python I can bind a socket in three statements, and one of them is 'import socket'.)

So today when I wanted to see how bind() behaved on Solaris 9, I fired up two interpreters in two windows, and in the first I typed:

>>> import socket
>>> s = socket.socket(); s.bind(('', 4000))

and in the other I typed:

>>> import socket
>>> s = socket.socket(); s.bind(('127.0.0.1', 4000))

And the Solaris 9 machine promptly spewed a traceback complaining about 'socket.error: (125, 'Address already in use')', just as I expected. (Yeah, I could have done it all in one Python interpreter; I didn't feel like seeing if Solaris did something funny if the same process was doing both bind()s. (It turns out it doesn't.))

A surprise with using object() instances

A while back I wrote about emulating C structs in Python using (instance) objects to create namespaces, and wrote:

(Avoid the temptation to just use 'ms = object()', because it hurts your ability to tell different types of structs apart via introspection.)

It turns out that there is another reason to avoid this: it doesn't work. Somewhat to my surprise, instances of object() can't have new attributes put on them. (Instances of Python subclasses of object() can.)

While I suspect that the behavior is deliberate, there's nothing in the CPython source code that singles out instances of object() for this. As far as I can tell, you can't set attributes on them mostly because they don't get any sort of attribute storage set up, such as an instance dictionary.

This does beg the question of what instances of object() are good for. As far as I can see the answer is pretty much 'creating minimal sized unique things as sentinel values', as I did in DefaultArgumentsTrick.

(Tracing through CPython source code out of curiosity is something I do every so often. It teaches me more about how CPython is put together, and it keeps me used to tracing how stuff flows through code I don't know (which is a quite useful skill to have).)