Why I love python.

[Nick Patavalis]

On 2004-08-13, Michael Scarlett <bitshadow at yahoo.com> wrote:
> There is an amazing article by paul graham about python, and an even
> better discussion about it on slashdot.

Yes, the article is very good

> Don't complicate it. Leave it as is. Work on making it faster, not
> uglier. 

Python needs drastic performance improvement if it is to scrap-off the
"scripting language" stigma. The only way to get these improvements is
making it possible for a python implementation to produce *efficient*
*compiled* code. At the same time the dynamic-typing nature of the
language is one of its most valuable characteristics. And this is one
of the hardest problems when trying to write a decent python
compiler. If you define a function like:

  def sum (a, b):
    return a + b

How can the compiler know what code to produce? It could trace all the
applications of sum(), and decide what types of arguments sum() is
actually applied on. But this is not easy, and sometimes it is
straight-out impossible.

A different approach would be for the programmer to *suggest* what
kind of types the function will *most probably* be applied on. The
programmer might suggest to the compiler that "a" and "b" will *most
probably* be integers or floats, so the compiler will have to produce
code for a function that handles these cases (or code for two
"functions", one for each case). One might say that the function could
be "decorated" by the programmer regarding the type of its
arguments. Notice that in such a case the decoration does not alter
the behavior of the function in any way! The function can still be
called with string arguments, in which case execution will be
dispatched to an "interpreted" version thereof.

So I believe is that "making it faster" requires some fundamental
work, and not simply devising "better algorithms for some
modules". Better algorithms for some modules will give you something
like point-something improvement in performance. Being able to produce
efficient compiled code will give you improvement between a factor of
10 and an order of magnitude (depending on the type of the
program). The same it true for "making it more secure" (e.g by
providing the programmer a way to specify what types of arguments are
*allowed* to be passed to a function).

In general, python must break free from its perl-ish adolescence
(language for small things, which doesn't have to be very fast or very
safe), but without loosing its agility. Decorators might be a step in
the right direction, or at least they might allow some experimentation
with such matters.

Because of this they are welcome.

Just my 2c
/npat