initializing mutable class attributes

[Dan Perl]

"Alex Martelli" <aleaxit at yahoo.com> wrote in message
news:1gjg2g0.1yx50mvx6csq3N%aleaxit at yahoo.com...
>    ...
> Nevertheless, the observation "you cannot have a default constructor and
> a non-default one at the same time" is not correct.  If you want to
> insist that the constructors MUST all be named __init__, otherwise
> they're not constructors but "methods which construct but we cannot name
> constructors because constructors must be named __init__", go ahead, but
> then, again, we are at an information-free tautology.  My point is: you
> can have any number of "methods which construct" (constructants? I think
> calling them constructors is more idiomatic English!-), just by choosing
> the same number of names, one each.  So drawing any conclusion from a
> premise that "you cannot have a default constructor and a non-default
> one at the same time" is faulty reasoning -- the premise is false (by
> any meaningful interpretation of the terms in it) so you can prove
> anything from it.  You may want to try and correctly deduce something
> from the true assertion -- "if you have a default constructor and a
> non-default one they must have two different names" -- but I don't think
> anything necessarily follows from this one.

We are arguing terminology.  I was strictly referring to __init__, but you
are certainly right that Python 'constructors' are a more loose term.

> Sure, this C++ code is faulty.  The way gcc diagnoses that error is
> debatable; I would say the fault is more likely to be a missing
> " :Class1(someinteger) " between the "Class2(int arg)" and the following
> open-brace.  I've made my life for years in a job where one of my main
> tasks was helping hundreds of programmers write good C++, I've seen this
> error often, and the "solution" of adding to Class1 a constructor
> callable without arguments was very rarely the right one; almost
> invariably those mandatory arguments in Class1's constructor _WERE_
> indeed logically necessary -- the class just could not make instances
> with meaningful internal state (meeting not just the class invariants,
> but the "business purpose" of the class) without those arguments.  The
> solution was (if the inheritance between concrete classes just could not
> be removed in favour of preferable idioms such as Martin's Dependency
> Inversion Principle) to ensure subclasses specified the needed arguments
> for their superclasses -- that's exactly what C++'s syntax
>
> Class2(int arg): Class1(someint) { ... }
>
> is _for_.  ("two-phase constructor" and other solutions also emerge
> here).
>
> In brief: given Class1 as it is, you have to call Class1's constructor
> explicitly in Class2's constructor, just like in Python (but with far
> less flexibility, because it needs to happen _before_ Class2's
> constructor body executes -- whence possible needs for two-phase
> constructor and the like).
>
> >  .....
>
> Or more likely, you have to call Class1's constructor explicitly from
> Class'2 constructor.  But sure, C++ does have more implicit, "black
> magic" behavior "behind the scenes" than Python in quite a few aspects
> (though not an unbounded amount) -- the implicit no-arguments do-nothing
> constructor is NOT an example, because the result is exactly the same
> you get in Python if you have no __init__ at all.

You're right, in most cases that would be the right use.  But my example was
just an example and it was just to enforce the earlier statement of "C++ and
Java have overloading and then can also mandate a default constructor for a
parent class."

> I've already explained how you can simulate C++'s behavior, and indeed
> get even MORE implicit if you wish, and I think it would be a disaster
> to USE such a custom metaclass; but if you're sincere in saying it's
> better then you should be KEEN to use it.  I'm supposed to do other
> things this evening (changing some scripts to generate DocBook rather
> than XHTML from some semantic-level markup -- fun, fun, fun...;-) but
> maybe I'll find the time to take a break and show you the custom
> metaclass you need to perpetrate this horror, since you state it's
> "better" than Python's explicitness -- no promises tho...

Thanks, but you don't have to bother.  It's not something I need right away.
But I should learn that for myself so I will look at your previous posting
and other documentation that I'll find.

Dan