initializing mutable class attributes

[Alex Martelli]

Dan Perl <dperl at rogers.com> wrote:

> I will clarify something that was probably not clear enough in my initial
> posting.  I am interested in instance attributes, but I am using the class
> attributes to provide a default, "null", value for the instance attributes.

Quite a reasonable approach for immutables, because you don't have to
worry about how to copy them -- only about rebinding, which only happens
on the instance anyway.  Not feasible for mutables, obviously, because
you WOULD have to worry about how to copy them -- shallow or deep, for
example?

> awkward, I would rather call it unsafe.  If I were a third-party library
> vendor, I would not be comfortable providing a mixin class that forces users
> to either invoke the parent's __init__ in their constructors or to

You're out of luck, then -- most well-designed classes, mixin or not, do
need to have their __init__ called in order to set a consistent state on
a new instance which will allow that instance to fulfill its
responsibilities.  Just copying (shallowly or deeply...?) some class
attributes ain't gonna cut it.

> I think this points to a weakness in Python as an OO language.  I'm not

I think that Python's having as few "hidden black magic thing that
happens when you're not looking" aspects is a strength, not a weakness.

> trying to bash it, but my understanding is that Python is still evolving in
> that respect and I think that this should be improved in the future.  Then,

Python's OO is still settling down after the huge changes in the passage
from 2.1 to 2.2 and it's unlikely that any change to come will include
making the calls to superclasses' __init__ methods somehow magical and
automatic rather than explicit -- I can't speak with certainty, only
Guido could, but that is my best guess.

However a custom metaclass that does automagically call some
initializers is surely a possibility, since it's a rather modest
investment of time to develop one, if anybody with a good understanding
of Python OO shares your opinion.  Calling initializer methods appear
self-obviously (to me) to be head and shoulders above your idea about
copying (deeply or shallowly?) some class attributes into instances, of
course.  And I would not call the automagically called initializers
__init__ to avoid conflicting with __init__'s very deliberately
NON-automagical behavior -- maybe something like __preinit__ or
__postinit__ depending on when you want these black magic methods
called, or __autoinit__ if you want to keep that aspect undefined, &c.

> on the other hand, maybe I'm the only one feeling this way and there's not
> going to be a change.

It's likely that others share your preferences, but if they share them
strongly enough to want to actually do something about them I think
they're more likely to be considering other languages, more suitable to
their overall philosophy -- it's rare, though not unheard of, for
somebody to stick with a language on which they differ on fundamental
points of design philosophy, and strive to change that language to their
own philosophy, when there are so many alternatives with different
philosophies that one might switch to instead.  Similarly, it would be
unusual, though far from impossible, for somebody to both have a
complete and perfect grasp of Python's object model (so they'd be the
kind of person who could implement a custom metaclass for your purposes
with comparatively little effort) and at the same time loathe
fundamental aspects of that object model enough to want to strive to
change them.  Nevertheless, these are only 'trends', not certainties.


Alex