initializing mutable class attributes

[Alex Martelli]

Dan Perl <dperl at rogers.com> wrote:
   ...
> > In this like in many other details, Python chooses simplicity and
> > clarity against automatic, black-magic, "behind the scenes" approaches.
   ...
> This is the kind of answer I was hoping for.  Actually, I was prepared to
> see a suggestion for solving the problem in a different way and there were a
> couple of them, even if the people suggesting them were themselves advising
> to prefer the original solution.

Glad I was helpful (in both ways).


> When learning something, I need to understand the 'WHY' behind a design
> decision like that, when clearly there are alternatives.  I will not be

I absolutely agree: understanding design rationale is crucial to using
complicated systems optimally.

> satisfied with an explanation of "that's the Python way and you just have to
> learn it".  The explanation of choosing "explicit" instead of "implicit"
> makes sense and helps me in better understanding Python.  I have to mention

I'm glad to hear this.

> though that I do not accept "explicit is better than implicit" as an
> absolute truth.  [That's like when someone told me once with pride: "I
> always design bottom-up."]  Applying a principle like that CONSISTENTLY in
> the design of a language can make a very good language.  On the other hand,
> I can imagine there can be very good languages, with their own uses and
> advantages, if the reverse principle were consistently used.

Perhaps, but from my experience with languages which consistently try to
double-guess programmer intent and "do what's right" implicitly based on
context, it doesn't work -- I'm thinking of PL/I, C++, Perl.  They're
all big languages, so perfect consistency is impossible, of course.  But
even small languages grow, if they're successful.  Do you have specific
examples in mind of very good languages based on "implicit is better
than explicit"?

> 
> You may see in another message I posted in this thread that I ended up
> giving an answer to my own question (the 'WHY' question).  Here is my reason
> for that 'WHY'.  Python does not have method overloading (and I am ok with
> that, because it comes with the dynamic typing), so you cannot have a
> default constructor and a non-default one at the same time.  C++ and Java

Not with the same name.  You can have all alternative constructors you
want if you give them different names -- that's a popular use of
classmethod (in Python as well as in Smalltalk, though there are
differences between the two, of course).  Alternative names are more
powerful than any overloading based on type could possibly be.
Consider:

>>> seq = (1,2), (3,4), (5,6)
>>> dict(seq)
{1: 2, 3: 4, 5: 6}
>>> dict.fromkeys(seq)
{(1, 2): None, (5, 6): None, (3, 4): None}

Overloading based on type would be powerless here, but classmethod
fromkeys of the dict class is perfectly usable to get a different
alternative constructor.

> have overloading and then can also mandate a default constructor for a
> parent class, even if it's empty because you actually use only a non-default
> constructor for that class.  Python cannot request that you also implement a
> default __init__ when you need a non-default one.  There would be the
> possibility of adding another special method, but there's already __init__
> and __new__, so that would be too confusing.

Java and C++ _could_ mandate a default ctor, but they don't -- it would
be a very bad design decision for them to do so, and their designers
aren't THAT bad:-).  It's perfectly possible to have a class that just
CANNOT be constructed without some specific arguments.

I'm not sure why different names would be confusing any more than
different signatures for the same name.  Indeed in practice C++ builds
names from signatures (with some added complications regarding hiding of
names apart from signatures).  So I don't think this rationale is a good
one for Python's design choices regarding object creation &
initialization.

> 
> I don't know whether that was an actual reason for the design even if it is
> definitely an obstacle.  But the principle of "explicit instead of implicit"
> (I'll think of it that way) will help me to understand also other aspects of
> Python.  And thank you for that.

You're welcome.  But I think the impossibility of having several methods
with the same name, differentiated only by signature, is not the root of
things in this particular case.


Alex