Things that Annoy Me About Python
8 PM
September 1, 2003
I really like Python, but there are a few rough edges I would happily see knocked off it.
In the big picture, there are two big problems with Python:
- Python does not have a great record corporate acceptance. The best way to increase its acceptance would be to use an alternate spelling for the name “Python”. I suggest “J-A-V-A”. That would to work.
Some language features get up my nose too:
- There are no closures. The Python syntax makes this a difficult addition. Update: Completely not true—see this new post
- Ditto with the ternary operator.
- There is no broad agreement on Python coding style. This is particularly annoying when it comes to class and method names, the number of spaces to indent1, an how comments should be written.
- There are no true declarations. The
class and def statements for creating classes and functions look like declarations, but their exact effect depends upon the program’s run time state when the class or def statement is run. While very powerful, this can lead to obscure bugs.
David also points to 10 Python Pitfalls by Hans Nowak and Python Gotchas by Steve Ferg. Both good reads.
1 Or indeed, whether to use tabs instead of spaces.
Comments
I agree with the documentation, but couldn't care less about corporate acceptance (although more Python jobs would be nice :-).
I don't really agree with what you say about the language features though...
- Python does have closures, they're just not as powerful like, say, Scheme's.
>>> def incmaker(x):
def inc(n):
return x + n
return inc
>>> plus4 = incmaker(4)
>>> plus4(4)
8
What cannot be done is create a variable in incmaker's namespace, set it to (e.g.) 42, and change (or rather rebind) that variable later. At least not without some trickery.
- I'm in the camp that didn't like the ternary operator. Enough about this; too much has already been said in the newsgroup.
- """There is no broad agreement on Python coding style. This is particularly annoying when it comes to class and method names, the number of spaces to indent1, an how comments should be written.""" I don't really see the point of having coding styles, and comments are written however you damn well want to write them. ;-) Most people seem to use 4 spaces for an indent. Tabs are evil. ;-)
- I guess the behavior of 'def' and 'class' can lead to obscure bugs, but I don't recall ever running into one.
That said, I suspect that everybody has their own list of Python pet peeves, largely incompatible with the lists of others. ^_^
A coding style is set out by Guido, and you're welcome to adopt it. The standard library code follows that style. See http://www.python.org/peps/pep-0008.html
As for the documentation being out of date - I'm not sure I see that. I think Fred Drake is pretty good at keeping the docs up to date with the latest release. For example, when I needed to know what __getattribute__ did in py2.2, I just needed to look in the language ref and it was there. Ditto for the optparse module added to py2.3. And so on...
Python 2.5 has a ternary operator. "42 if cond else 24" will produce 42 if cond is true, otherwise it will produce 24.