no return values for __init__ ??

Aahz Maruch aahz at netcom.com
Mon Jan 10 01:53:30 EST 2000


In article <3879074F.1A4EDED3 at mdlink.de>,
Helge Hess  <helge.hess at mdlink.de> wrote:
>Aahz Maruch wrote:
>> Helge deleted his own attribution here:
>>>
>>>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.

Well, no, not in my experience.  It seems pretty obvious to me that
__init__ is a special method that is only called at object
instantiation.  Object instantiation requires that the constructor
return the object created.  __init__ gets called by the constructor to
ensure that the returned object is in a valid state, and it seems
reasonable to me that __init__ cannot substitute a different object for
the constructor to return.

>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.

That is essentially correct.

>> 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)).

OTOH, the __getslice__ method (for example) requires that the returned
object be some sort of list or tuple.  It is possible, of course, to
pervert all of these interfaces, but I think that their clarity is a
great strength of Python.

Of course, you can also call the special methods directly, but that is
strongly discouraged, and if you fail to conform to the interface you
are likely to run into problems with Python calls them automatically.
--
                      --- Aahz (@netcom.com)

Androgynous poly kinky vanilla queer het    <*>     http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

Have a *HAPPY* day!!!!!!!!!!



More information about the Python-list mailing list