Python future performance and speed

[Jacek Generowicz]

beliavsky at aol.com writes:


> (2) The Python approach to OOP is very different -- looser -- than
> that of C++ and has less support for data hiding. For example, one can
> add an attribute to an object anywhere, which seems like a dubious
> freedom to me.

Seems like a damn useful freedom to me. But then I've worked with
people who refused to take the obvious clean, efficent, clear design
decision only because it violated some principle they were told about
in some OOA&D class ... only to insist on creating a program which was
slow, ugly, difficult to understand, difficult to maintain, and had a
few less useful features.

> (3) The beginning of a Python function only tells you about the
> arguments, not the result. I prefer not to scan the entire body of a
> function to see what it returns. Compiled languages like C++, Fortran,
> and Pascal put the argument and result info in one place.

And compiled lanugages like Lisp[1] and Python[2] don't. Oh, you meant
"explicitly statically typed", rather than "compiled", I see :-)

But caring about the type to this extent is not a very productive way
of programming in Python. You should understand the purpose of the
function, and thereby understand the duck types it accepts and returns
... and duck types are not expressible in a way that wouldn't make a
explicitly static compiler smoke.

Of course, those coming from the bondage school of programming (C++,
Java ...) will run screaming when confronted with duck typing, but
that's their loss.

> (4) Python does not look like C++. Some programmers think that any
> alternative to C++ must still look like it. I think this argument is
> weak, but Java's cosmetic similarity to C++ probably has boosted its
> popularity.

This is one of the greatest tragedies: C++ is accepted as the starting
point. We're doomed.



[1] Compiled to native machine code (usually).

[2] Compiled to bytecode (usually).