Why Python?

http://www.linuxjournal.com/article/3882/#

by ryanwaggoner • 16 years ago

91 59 16 years ago

hartror• 16 years ago

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

silentbicycle7• 16 years ago

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)

miloshasan3• 16 years ago

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.

ekiru• 16 years ago

How is this so? Decorators are just syntactic sugar for defining a function then replacing it with the result of calling another function (the decorator) on it.

neild• 16 years ago

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.

silentbicycle7• 16 years ago

My complaint mixed two things - one, I'm not convinced that decorators are a special-case "feature" that would come for free with better lambdas. Two, does Python need tuples, dicts, AND lists? (I know it's had them for a long time.)

Python seemed really refreshingly clean compared to Perl and C++, the languages I'd been using previously. I still think it's a decent language, but Python is to Perl and Lua is to Python along those lines. I've moved on.

I'm probably still just annoyed about Guido's position on tail-call optimization, though.

baddox2• 16 years ago

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.

cabalamat3• 16 years ago

> 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).

I am in favour of semantic sugar, I just don't think it should be part of the language. Languages should be small, and have features that enable syntactic sugar to be written in the language. These features might include macros (like in Lisp, or at a pinch C) or overloaded operators (as in C++ or Python).

Regarding decorators, I don't see that they bring much value. The decorator syntax is no shorter than doing it without decorators, so if you remove the decorator syntax you're making Python a smaller language which makes it easier to learn and understand.

cabalamat3• 16 years ago

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)

wyuenho3• 16 years ago

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.

wkornewald• 16 years ago

I've implemented a Python-inspired syntax for JavaScript which supports multi-line lambdas. This is what it looks like:

http://bitbucket.org/wkornewald/pyvascript/src/tip/pyvascrip...

It would look better with syntax highlighting, but I'm not sure if the code stays readable enough with multi-line lambdas.

It also becomes more ugly once you want to use lambdas within dicts or lists: http://bitbucket.org/wkornewald/pyvascript/src/tip/tests/tes...

The problem here is that

return x,

could be either a lambda returning the tuple (x,) or the dict/list item separator, so the separator must be put on a separate line.

I'm sure something like this was already proposed, so what were Guido's objections against it? I suppose it's not possible to make multi-line lambas readable enough?

Maybe we need more powerful IDEs that go beyond editing text in a "stupid" text field and instead work directly on the AST and use other visual hints like boxes around functions/lambdas, etc.

rwmj5• 16 years ago

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.

viraptor3• 16 years ago

- 64 bit issue is going to be the same for all languages. Twice the pointer size, twice the data size (unless you're using a very specific type)

- No code generators? You could complain that they're not good enough, don't support some specific extensions, don't play nice with threading, or something else, but there are many versions of python which work as compilers. Just google a bit.

- Lack of type safety is there by design. If you want type checking, why are you even looking at duck-typed scripting languages? It's a basic design decision, not something that could be changed / improved.

- Why is whitespace even an issue in patches? If anyone submits a patch, they should use exactly the same style as the rest of the file. If they don't, patch should be rejected. The same thing happens in projects where indentation doesn't really matter. Also, it's hard to "silently" screw up code covered by tests. Any big enough project should have those...

gaius4• 16 years ago

The problem with Red Hat is it's stuck on Python 2.4. Altho' the hassle of persuading the SAs to install ActiveState too was what led me to OCaml, so it's not all bad :-D

Daishiman• 16 years ago

Your complains sound more about dynamic languages in general than Python.

zephyrfalcon• 16 years ago

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.)

msie• 16 years ago

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.

okmjuhb• 16 years ago

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.

Macsenour• 16 years ago

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

silentbicycle7• 16 years ago

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• 16 years ago

Use what you know best right now.

henning• 16 years ago

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

alexyoung• 16 years ago

"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.

bokchoi• 16 years ago

In the year 2000.

Tycho• 16 years ago

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• 16 years ago

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.

Estragon• 16 years ago

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.

Why Python?

Related Stories