Backward chaining for __init__?
Courageous
jkraska1 at san.rr.com
Wed May 3 02:15:22 EDT 2000
> 1) If the base class's constructor takes arguments, how will you
> know which arguments to provide?
The function that has the right profile?
> 2) If we're using multiple inheritance, which ctor do we call first?
Decisions, decisions.
> 3) What if we want to initialize some of the object's state before we
> call the ctor? (This is unusual, but not IMO completely pathological.)
Kind of like an :after make-instance method in Lisp,
where the semantic is that all the :initargs go first,
then the :after ctor is called. Very nice functionality,
that. And entirely optional all the way around.
> Personally, I like Python's approach because it makes the chaining
> explicit.
Well, now this isn't so bad, actually. But how about:
class Foo
def chaining __init__(self)
dosomething()
This would provide the semantic that all classes inheriting
from this class would chaining __init__ methods
all the way down the inheritance tree. A general utility,
which could be used in other contexts.
Mostly I'm worried about certain __init__ methods which
are required to be called on a class for the class to even
make sense. I'd like to be able to say "if you're usin' my
class, bud, you're doin' it my way".
C/
More information about the Python-list
mailing list