Python's biggest compromises

[Ian Bicking]

On Thu, 2003-07-31 at 08:55, Anthony_Barker wrote:
> The three that come to my mind are significant whitespace, dynamic
> typing, and that it is interpreted - not compiled. These three put
> python under fire and cause some large projects to move off python or
> relegate it to prototyping.

I think these are valid as "compromises", not to be confused with
flaws.  These are all explicit choices, and ones for which the original
justifications remain valid.  A lot of stuff in Basic is simply flaws,
or based on justifications that no longer apply to today's programming
world.


Anyway, I might add mine: the nature of modules as executed code is a
compromise.  That is, a module isn't a declaration, it's a program to be
executed in its own namespace.  When you import a module, you are
executing the module then looking at the namespace.

There are some advantages to this, particularly in the transparency of
the implementation -- things don't always work the way you might want
(e.g., circular imports), but it's usually not that hard to understand
why (and often the way you want things to work has nasty gotchas that
you wouldn't have thought of).  It also opens up a lot of possibilities
for dynamicism in class and function declaration, like doing this in the
top level:

if something:
    def func(x): ...
else:
    def func(x): ...

But it's a compromise, because it makes things more difficult as well. 
It's a *big* problem in any long-running process, where you may want to
modify code underlying the system without rebuilding the entire state. 
Classes aren't declared, they are simply constructed, so by reloading a
module all the persistent instances still exist and refer to the defunct
class.  You can modify classes at runtime, but this is different from
simply rerunning the class definition.  (A clever metaclass *could* make
those equivalent, though... hmmm...)

A related problem is that Python objects generally can accept any
instance variable names, and names are not declared anywhere.  Again,
this makes it difficult to deal with long-lived objects.  If you change
the class so that all instances get a new attribute, old objects won't
be updated.  I'm thinking about both of these things in terms of
Smalltalk, where they make tools possible that really add to the ease of
developing in its environment.

Not that I don't like the fun tricks Python lets you do.  Prototype-like
programming (as in Self) is very accessible in Python, and classes are
only a suggestion not a dominant concept.  So, it's a compromise.

There are lots and lots of compromises in Python -- every aspect has
pluses and minuses to it.  Personally I like whitespace sensitivity well
enough, but in the larger sense I think it probably was the wrong choice
-- but that's based on how I weigh various benefits and problems, and
other people will validly weigh them differently.  

  Ian