no return values for __init__ ??

[Helge Hess]

Aahz Maruch wrote:
> >Hm, I wonder why it is simpler to have two separate kinds of methods
> >instead of a consistent behaviour for all methods ?
> 
> Because we're looking at it from two different perspectives.  You're
> looking at the process from the bottom and I'm looking at it from the
> top.  Providing your capability would make it too easy for an
> inexperienced programmer to screw things up royally.

I can't see on what you base this statement on ?! This capability
generalizes, not specializes, the environment - which leads me to the
assumption that the *current* state will make programmers wonder.

Until now I haven't heard a reason against this 'feature' which I can
follow. I guess that it is just a matter of taste.

> I think one point that you're missing is that double-underscore methods
> in general do not follow the straight standard method paradigm; they all
> have restrictions on their interface.

Really ? I was not aware of that, I thought that I could call all
methods as usual and that the only 'special' thing is, that they are
automatically called by the system.
For example '__getattr__', it is a method like any other. Eg although
the system always calls __getattr__ with a single parameter, you could
still define the method as 'def __getattr__(self, *args, *kwArgs)' and
use it in different context's too (whether this makes sense is another
question, eg for __init__ it could make sense (to reinitialize the
instance)).

Greetings
  Helge
-- 
SKYRIX-OS  Web Application Environment - http://www.skyrix.com
SKYRIX-IAS Groupware Application Suite - http://www.skyrix.com