no return values for __init__ ??

[Helge Hess]

Gordon McMillan wrote:
> >   def __init__(self...
> >      s = super.__init__(self...
> 
> OK, but it introduces a "gotcha". As in, what happened to the
> stuff I set up before calling super.__init__, (which is not only
> valid, but often useful).

I don't know what you mean with that. It is deallocated if another value
is returned and available to super.__init__ as usual. super.__init__ can
base it's decision about the value to return on state already set up in
self as well.
I cannot see a problem here.

> > BTW: I also always wondered why Python has None as the default
> > return value. 'self' seems better to me as one could make
> > compound method calls without additional work while None has no
> > benefit I can see (maybe better RC behaviour ?).
> 
> It's consistent with function behavior (which has no self to
> return), and after all, a method (when viewed on the class
> object) is a function.

Yes, that's seems understandable to me. Maybe it would have been cool if
functions would have been methods on their namespace/module :-)

> With yet more "gotchas".  The (one and only) base class
> constructor that could change "self" would have to be the first
> one executed.

No, why so ? Do you care about partial state in __del__ ?? The one who
uses such a setup is also responsible for resolving such a setup (and
this is easily possible).
Again that is similiar with any other method and MI.

> > There is no conceptual difference between __init__ returning a
> > value and any other method returning a value.
> 
> Not if you don't accept the axiom that __init__ is "just another
> method". In fact, as an initializer, __init__ is a lot less special
> that constructors are in most languages.

Well, in Objective-C and Smalltalk there isn't a thing like a
'constructor'. In Python and Java 'constructor' IMHO only means 'method
with special syntax for invocation' since such methods are not
participating in allocation.

Greetings
  Helge