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