Why Python?

[Tycho]

Fascinating statement:

Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code.

[fnl]

A bit wired but its really a fun read that many years later - although the truth is, his reasons for the swap in the end were probably the same as mine (although even later, because my team then wasn't using Python). And I still think Python beats any other in syntactic beauty by simplicity. Although Lua is a nice solution, too - I just don't like the end.

[silentbicycle]

I wonder how much of this is still true. Python was a very compact language a decade ago (when I started using it), but gradually acquired bloat (perhaps because people switching from Java demanded it - decorators* ? tuples AND dicts AND lists?). I later switched to Lua, which on the whole is very similar, but has constraints that have made it stay compact.

* Seriously - downvoters, explain. What do decorators actually add that wouldn't come free with non-broken lambdas? I've tried to make sure I'm not missing something, but they seem like a gratuitous workaround.

    @dec
    def somefunc(x, y):
        blabla

vs.

    somefunc = dec(fun (x, y)
        blabla)

[neild]

You complain that Python has acquired bloat in the past decade, and appear to be citing the presence of tuples, dicts, and lists as an example of this. Since tuples, dicts, and lists have existed in Python for well over a decade, I don't quite see how they can be an example of acquired bloat.

As for decorators...well.

    @dec
    def somefunc():
        pass

is almost precisely identical to

    def somefunc():
        pass
    somefunc = dec(somefunc)

In other words, decorators are pure syntactic sugar. I suppose you could call that "bloat", although I'd rather strongly disagree. There's nothing at all wrong with making common patterns easier to write, and I've written plenty of code which has benefited from access to decorators.

What really puzzles me is that it seems that what you really want is simply added syntax for multi-line anonymous functions...in other words, syntactic sugar. I suppose that "bloat" is any sugar that doesn't come in your preferred flavor.

[wyuenho]

Decorators and lambdas are completely different and separate topics, one CAN exist without the others.

A decorator is a function that takes a function, optionally some parameters and return a function. What this tells you is that a decorator is a special instance of a higher-order function, that takes a (partially applied) function, fudge around with its internals and return that same function, fully applied. When I said function, they can be named of course, which is the case for most of the Python functions.

Your second example would accomplish the same thing, but let's change it to something like this:

  somefunc = dec(def (x, y):
      blabla)

However, this proposal instead of introducing a new language syntactic feature, you would have to change how the interpreter parses and compiles function argument, namely it'll need to understand a def function definition without a name as an expression. The interpreter would also need to assign an internal name to the lambda and compile it to a function object.

That's not a trivial change in the grammar of the language. However, I'd agree that having that instead of a Python lambda would make a lot of HO functional style programming a lot more fluid.

[zephyrfalcon]

Hmm, Python had tuples, lists, dicts and classes from the very beginning (version 0.9.1). Much bloat was tacked on after the simple class model was deprecated in favor of new-style classes... class methods, static methods, metaclasses, descriptors, properties, decorators, you name it. Then there were additions like list comprehensions and generators (although those are actually useful).

IMHO, Python's indentation-based syntax is a great way to make (and keep) the language readable, but at the same time it's an impediment to language flexibility. In a more flexible language, you could have implemented most (or all) of the aforementioned features yourself. (This sounds like something a Lisper would say, but it would work in other languages as well, like Io and Ruby.)

[baddox]

Decorators are just syntactic sugar. Are you arguing against syntactic sugar and perhaps for a slimmer "purer" syntax? If so, I think that's a valid point (though I happen to disagree in this case).

All syntactic sugar actually adds nothing: we don't need +=, ++, or even C-esque array indexing. However, they often provide easier to read/write/maintain source code.

As for Python decorators, one easy example of why they're neat is in Django: you've got your view functions, and if you want to restrict access to a view to only authenticated users, you add the line "@login_required" right about the function definition. I happen to think it looks nice.

[miloshasan]

Didn't downvote you, but the difference is that lambdas can only be executed (i.e. applied to something) while decorators let you analyze the code of the function and do something else other than just executing it.

[cabalamat]

or, more usually one of these:

    def somefunc(x, y):
        blabla
    dec(somefunc)

    def somefunc(x, y):
        blabla
    somefunc = dec(somefunc)

The rationale for decorators, AIUI, is that if somefunc() is long, then putting the decorator at the end makes it easier to overlook, whereas putting it at the top is harder to overlook. Personally, I never use them; if I want the functionality of decorators, I write code immediately after the function, e.g.:

   def add(a, b):
      r = a.getValue() + b.getValue()
      return sm.UInteger(r)
   notify(add, "ii", "i", "+", cascade=True)

BTW, lists, tuples and dicts have been in Python since forever (at least as far back as 0.9.1)

[okmjuhb]

I'm surprised no one has mentioned yet what I regard as the key reason decorators are useful: they maintain the property that you can always find the definition of a function named "foo" by textually searching for "def foo". Lots of alternate syntaxes break that.

[rwmj]

Don't know about decorators. The real issues with Python that I find working at Red Hat (unfortunately Python and Ruby are popular choices here):

- generally poor choices for implementation: inefficient storage of values

- 64 bit version approximately doubles the size of all data

- interpreted, no code generator so it's very slow

- lack of type safety is a constant source of bugs that just wouldn't appear in other languages

- whitespace layout screws up patches silently

Edit: don't downvote, comment on what I have to say.

[msie]

I think you can go too far in keeping a language compact. If there are common patterns in programming then they should be captured in the language. It makes code easier to write and understand.

[henning]

Ah, vintage, pre-batshit crazy ESR. Not a single instance of referring to anyone and everyone who disagrees with him as an "idiotarian."

[alexyoung]

"Perl still has its uses. For tiny projects (100 lines or fewer) that involve a lot of text pattern matching, I am still more likely to tinker up a Perl-regexp-based solution than to reach for Python."

I liked this comment because it sounds a bit like he was saying Perl was long in the tooth. 10 years later, Perl still has its uses, and it's still used commercially.

It's also possible to enjoy languages other than your One True Favourite-Ever Language. I'm aware this might sound insane, but I'm going to leave this Python script I'm writing to fix some bugs in a Ruby gem I'm working on, and then go back to writing a daemon in Node JavaScript. Because they all have their uses and you don't need to troll/defend your favourite at every opportunity.

[hartror]

This is pretty much my experience of learning Python but I had had drastically less coding experience than Eric Raymond did when he learnt.

[Estragon]

I came over here to say this article is about 10 years late, then noticed it was written in 2000, so I guess it was a tiny bit ahead of its time.

With python so mainstream today, I am not sure what its contemporary interest is, though.

[Macsenour]

As I struggle to figure out which language to use for my Facebook game... this is not helping. :)

[silentbicycle]

Don't let the perfect be the enemy of the good.

The concerns of people designing programming languages are different from people who want to write stuff today. Python is a reasonable choice.

[Devilboy]

Use what you know best right now.

[bokchoi]

In the year 2000.