initializing mutable class attributes

[Dan Perl]

"Alex Martelli" <aleaxit at yahoo.com> wrote in message
news:1gje9dn.r6jpetyroi0N%aleaxit at yahoo.com...
>  ............
> > No one, including you, has given me a reason WHY __init__ is implemented
> > this way.  I am not bashing you for that, I would just still like to
hear
> > that 'WHY'.  I'm sure that this implementation has some advantages.
But,
> > coming from a C++ and Java background, where parent default constructors
are
> > automatically invoked (well, not always, and that is something that
users
> > have to learn too), I find that that approach has some clear advantages.
>
> In this like in many other details, Python chooses simplicity and
> clarity against automatic, black-magic, "behind the scenes" approaches.
> "Explicit is better than implicit" is one part of the Zen of Python that
> speaks to this -- at a python interactive prompt do
>     import this
> to read it all.  The automatic invocation of default constructors when
> they exist, what you have to do instead to get different constructors
> for parent classes, etc etc, are all complications.  When classes are
> designed to execute responsibilities it's not unusual that they can't
> really have a useful no-arguments constructor -- and when they don't
> have such a constructor, C++'s and Java's rules are nothing BUT overhead
> and conceptual complication.  In C++ one often works around the burden
> of contraints on constructor calls via "two-phase constructors" -- a
> default constructor that does not really leave the instance in a usable
> state, just to bypass the darn rules you find "have some clear
> advantages", and then a normal member function that really does the job
> of initialization and has the enormous advantage that YOU decide when
> and with what arguments to call it, without all the darn rules in the
> way, explicitly.  Well, in Python the constructor, __init__, is under
> you control in exactly this way -- less complication, more simplicity,
> more transparency, fewer rules to learn, and far fewer instances of the
> "two-phase constructor" pattern (not zero, mind you -- just 99% fewer).

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.

When learning something, I need to understand the 'WHY' behind a design
decision like that, when clearly there are alternatives.  I will not be
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
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.

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

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.

Dan