Lawrence D'Oliveiro wrote:
> In article <[EMAIL PROTECTED]>,
> "Carl Banks" <[EMAIL PROTECTED]> wrote:
>
>
>>bruno at modulix wrote:
>>
>>>[EMAIL PROTECTED] wrote:
>>>
I was wondering, why you always have to remember to call bases'
constructors
>>>
>>>
>>>s/constructors/__init__/
>>>
>>>
Lawrence D'Oliveiro wrote:
> In article <[EMAIL PROTECTED]>,
> "Carl Banks" <[EMAIL PROTECTED]> wrote:
>
> >bruno at modulix wrote:
> >> [EMAIL PROTECTED] wrote:
> >> > I was wondering, why you always have to remember to call bases'
> >> > constructors
> >>
> >>
> >> s/constructors/__init__/
> >
Lawrence D'Oliveiro wrote:
>>In other words, the object is constructed in Python before any
>>__init__ is called, but in C++ it isn't constructed until after all
>>the base class constructors have returned.
>
> But if "construction" is what a constructor does, then you're wrong.
>
I may be wrong
In article <[EMAIL PROTECTED]>,
"Carl Banks" <[EMAIL PROTECTED]> wrote:
>bruno at modulix wrote:
>> [EMAIL PROTECTED] wrote:
>> > I was wondering, why you always have to remember to call bases'
>> > constructors
>>
>>
>> s/constructors/__init__/
>>
>> the __init__() method is *not* the construct
In article <[EMAIL PROTECTED]>,
Duncan Booth <[EMAIL PROTECTED]> wrote:
>Carl Banks wrote:
>
>> You know, Python's __init__ has almost the same semantics as C++
>> constructors (they both initialize something that's already been
>> allocated in memory, and neither can return a substitute object).
Brian van den Broek wrote:
> Bruno Desthuilliers said unto the world upon 25/04/06 06:52 PM:
>
>> Duncan Booth a écrit :
>>
(snip)
>>> Apart from the fact that you can delete the method 'dothis' from both
>>> classes with no effect on the code?
>>
>> Mmmm... Oh, I see. Agreed, this is not a very g
Bruno Desthuilliers said unto the world upon 25/04/06 06:52 PM:
> Duncan Booth a écrit :
>
>>bruno at modulix wrote:
>>
>>
>>
>>>class Base(object):
>>> def __init__(self, arg1):
>>> self.attr1 = arg1
>>> self.dothis()
>>>
>>> def dothis(self):
>>> return self.attr1
>>>
>>>class Derived(Base
Duncan Booth wrote:
> bruno at modulix wrote:
>
>
>>It's *already* split : __new__ construct the object, __init__
>>initialize it.
>>
>>>That's why I would go for the 2-phase construction:
>>
>>But that's already what you have.
>
> Very good point.
>
>
>>>after the first phase
>>>you have an
bruno at modulix wrote:
> It's *already* split : __new__ construct the object, __init__
> initialize it.
>
>> That's why I would go for the 2-phase construction:
>
> But that's already what you have.
Very good point.
>> after the first phase
>> you have an object which is fully initialised,
Duncan Booth wrote:
> Alex Martelli wrote:
>
> >> What I think I'm trying to get at is that I believe that most
> >> situations where someone actually tries to do something in the base
> >> initialiser which requires calling a virtual method are probably also
> >> cases where the initialiser is do
Duncan Booth wrote:
> Alex Martelli wrote:
>
>
>>>What I think I'm trying to get at is that I believe that most
>>>situations where someone actually tries to do something in the base
>>>initialiser which requires calling a virtual method are probably also
>>>cases where the initialiser is doing t
Alex Martelli wrote:
>> What I think I'm trying to get at is that I believe that most
>> situations where someone actually tries to do something in the base
>> initialiser which requires calling a virtual method are probably also
>> cases where the initialiser is doing too much: i.e. separating th
Duncan Booth <[EMAIL PROTECTED]> wrote:
...
> Actually, this is quite an interesting example becaue it wouldn't work in
> C++: if you tried the same trick the call to dothis from the base
> constructor (even assuming it is virtual) would actually call Base.dothis.
Yep.
> I think you have demo
Duncan Booth a écrit :
> bruno at modulix wrote:
>
>
>>class Base(object):
>> def __init__(self, arg1):
>>self.attr1 = arg1
>>self.dothis()
>>
>> def dothis(self):
>>return self.attr1
>>
>>class Derived(Base):
>> def __init__(self, arg1, arg2=0):
>>self.attr2 = arg2
>>Base.
bruno at modulix wrote:
> class Base(object):
> def __init__(self, arg1):
> self.attr1 = arg1
> self.dothis()
>
> def dothis(self):
> return self.attr1
>
> class Derived(Base):
> def __init__(self, arg1, arg2=0):
> self.attr2 = arg2
> Base.__init__(self, arg1)
>
> de
Duncan Booth wrote:
> bruno at modulix wrote:
>
>
>>Duncan Booth wrote:
>>(snip)
>>
>>>Usually though, if a subclass doesn't immediately call the base class
>>>constructors as the first thing it does in __init__ it indicates poor
>>>code and should be refactored.
>>
>>Not necessarily. It's a comm
Duncan Booth wrote:
> In other words, the object is constructed in Python before any __init__ is
> called, but in C++ it isn't constructed until after all the base class
> constructors have returned.
That's true. Good point.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Carl Banks wrote:
> You know, Python's __init__ has almost the same semantics as C++
> constructors (they both initialize something that's already been
> allocated in memory, and neither can return a substitute object).
There is a significant difference: imagine B is a base type and C a
subclas
bruno at modulix wrote:
> [EMAIL PROTECTED] wrote:
> > I was wondering, why you always have to remember to call bases'
> > constructors
>
>
> s/constructors/__init__/
>
> the __init__() method is *not* the constructor. Object's instanciation
> is a two-stage process: __new__() is called first, t
bruno at modulix wrote:
> Duncan Booth wrote:
> (snip)
>> Usually though, if a subclass doesn't immediately call the base class
>> constructors as the first thing it does in __init__ it indicates poor
>> code and should be refactored.
>
> Not necessarily. It's a common case to have some computati
[EMAIL PROTECTED] wrote:
> Heiko Wundram wrote:
> > Because sometimes you don't want to call the base classes constructors?
> Sounds strange to me at the moment, but I'll try to adjust to this
> thought.
In Java and C++, classes have private members that can only be accessed
by the class itself (a
[EMAIL PROTECTED] wrote:
> I was wondering, why you always have to remember to call bases'
> constructors
s/constructors/__init__/
the __init__() method is *not* the constructor. Object's instanciation
is a two-stage process: __new__() is called first, then __init__().
--
bruno desthuillier
Duncan Booth wrote:
(snip)
> Usually though, if a subclass doesn't immediately call the base class
> constructors as the first thing it does in __init__ it indicates poor code
> and should be refactored.
Not necessarily. It's a common case to have some computations to do/some
attributes to set i
[EMAIL PROTECTED] wrote:
> Heiko Wundram wrote:
>> Because sometimes you don't want to call the base classes constructors?
> Sounds strange to me at the moment, but I'll try to adjust to this
> thought.
It makes sense in more static languages such as C++. The base class is
initialised by the con
> Well, I can imagine it's done to make sure that the base(s) are
> properly constructed. Sound s sensible to me.
It often is - there are popular examples in python where missing a
constructor will cause a program to fail spectacular. But is it _always_ a
sensible thing to do? No. If you only want
[EMAIL PROTECTED]:
>I think I'll need some shift in thinking after C++.
+1 qotw
--
René Pijlman
--
http://mail.python.org/mailman/listinfo/python-list
Heiko Wundram wrote:
> Because sometimes you don't want to call the base classes constructors?
Sounds strange to me at the moment, but I'll try to adjust to this
thought.
> Python zen says: "Better explicit than implicit," and in this case it hits
> the nail on the head. Better to see right away
Diez B. Roggisch wrote:
> I have another question for you: why does JAVA enforce that a constructor of
> a base-class must be called prior to everything else in the derived class's
> constructor?
Well, I can imagine it's done to make sure that the base(s) are
properly constructed. Sound s sensible
[EMAIL PROTECTED] wrote:
> I was wondering, why you always have to remember to call bases'
> constructors explicitly from the derived class constructor? Why hasn't
> this been enforced by the language?
I have another question for you: why does JAVA enforce that a constructor of
a base-class must
Am Dienstag 25 April 2006 12:34 schrieb [EMAIL PROTECTED]:
> I was wondering, why you always have to remember to call bases'
> constructors explicitly from the derived class constructor? Why hasn't
> this been enforced by the language?
Because sometimes you don't want to call the base classes cons
[EMAIL PROTECTED]:
>I was wondering, why you always have to remember to call bases'
>constructors explicitly from the derived class constructor? Why hasn't
>this been enforced by the language?
Probably because the language doesn't know whether the subclass wants to
override its base class's constr
I was wondering, why you always have to remember to call bases'
constructors explicitly from the derived class constructor? Why hasn't
this been enforced by the language?
--
http://mail.python.org/mailman/listinfo/python-list
32 matches
Mail list logo
