Python's biggest compromises

[John Roth]

"Ian Bicking" <ianb at colorstudy.com> wrote in message
news:mailman.1059679007.20588.python-list at python.org...
> 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.

I think I'd go with your first assessment. These are design choices.
Compromises are things that you can't figure out how to get right
within the structure of the major design choices.


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

I wouldn't call it a compromise, but it does have its bad points
when you're trying to construct a large, reliable system.

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

Well, while that is true in detail, if you put the prototype in the
class object, all instances will find it the next time they try to
access it. References will get the class version, and assignments
will update the instance. Of course, you had to change some of
the methods to even get into this situation...

John Roth

>
>   Ian
>
>
>