Thanks,
Did not know that.
Philippe
Dennis Lee Bieber wrote:
> On Thu, 27 Apr 2006 14:32:15 -0500, Philippe Martin
> <[EMAIL PROTECTED]> declaimed the following in comp.lang.python:
>
>>
>> What then is the point of the double underscore (if any) ?:
>
> To prevent masking/shadowing of inhe
Dennis Lee Bieber wrote:
> On Thu, 27 Apr 2006 14:32:15 -0500, Philippe Martin
> <[EMAIL PROTECTED]> declaimed the following in comp.lang.python:
>
>> What then is the point of the double underscore (if any) ?:
>
> To prevent masking/shadowing of inherited attributes...
Note that it can fa
Thanks for all the useful answers :)
Alot of stuff to take into consideration/chew on. I come up with
similar drawbacks now and then, 'cause some OOP techniques can be made
in Python relatively simpler or plainly different (still simpler
though). Though I am hesitant on how to act on certain occas
Philippe Martin wrote:
> I'm not sure I understand what you mean ... I did get a strange new
> message from my email client and disabled the signature.
Look again at the post I replied to (great-grandparent of this one). It's
not your sig quote that was the problem.
--
http://mail.python.org/ma
Duncan Booth wrote:
> Philippe Martin wrote:
>> Steven Bethard wrote:
>>> [Please don't top-post]
>>
>> OK I won't, is that a general rule? (I've been top posting for quite some
>> time now and it is the first time I see that warning)
>
> Yes. Other suggestions you might get are not to bottom po
Edward Elliott wrote:
> Philippe Martin wrote:
> ''
>
> On the other hand, foo.__doc__ and foo.__name__ work fine.
>
> (I was going to quote your post but my reader interprets everything after
> the two dashes as your sig and ignores it. And I won't bother to fix it.)
I'm not sure I understan
Philippe Martin wrote:
''
On the other hand, foo.__doc__ and foo.__name__ work fine.
(I was going to quote your post but my reader interprets everything after
the two dashes as your sig and ignores it. And I won't bother to fix it.)
--
http://mail.python.org/mailman/listinfo/python-list
Philippe Martin wrote:
> Steven Bethard wrote:
>> [Please don't top-post]
>
> OK I won't, is that a general rule? (I've been top posting for quite some
> time now and it is the first time I see that warning)
Yes. Other suggestions you might get are not to bottom post, and certainly
not (as you d
Edward Elliott wrote:
> Panos Laganakos wrote:
>> i.e. we usually define private properties and provide public functions
>> to access them, in the form of:
>> get { ... } set { ... }
>>
>> Should we do the same in Python:
>> Or there's no point in doing so?
>>
>> Some other techniques come to mi
Panos Laganakos wrote:
> i.e. we usually define private properties and provide public functions
> to access them, in the form of:
> get { ... } set { ... }
>
> Should we do the same in Python:
> Or there's no point in doing so?
>
> Some other techniques come to mind, but I think that Python tends
Steven Bethard wrote:
> [Please don't top-post]
>
> Steven Bethard wrote:
> > Panos Laganakos wrote:
> >> we usually define private properties and provide public functions
> >> to access them, in the form of:
> >> get { ... } set { ... }
> >>
> >> Should we do the same in Python:
> >>
> >
Panos Laganakos wrote:
> I've been thinking if there's a point in applying some specific OOP
> techniques in Python as we do in other languages.
Yes - but some of these techniques are somewhat python-specific.
> i.e. we usually define private properties and provide public fu
[Please don't top-post]
Steven Bethard wrote:
> Panos Laganakos wrote:
>> we usually define private properties and provide public functions
>> to access them, in the form of:
>> get { ... } set { ... }
>>
>> Should we do the same in Python:
>>
>> self.__privateAttr = 'some val'
>>
>> def
Why is that ? to me it makes sense when I see self.__m_var that I'm dealing
with a member variable taht derived classes will not see/access.
Philippe
Steven Bethard wrote:
> Panos Laganakos wrote:
>> we usually define private properties and provide public functions
>> to access them, in the f
Panos Laganakos wrote:
> we usually define private properties and provide public functions
> to access them, in the form of:
> get { ... } set { ... }
>
> Should we do the same in Python:
>
> self.__privateAttr = 'some val'
>
> def getPrivateAttr(self):
> return self.__privateAttr
>
> Or th
Panos Laganakos wrote:
> i.e. we usually define private properties and provide public functions
> to access them, in the form of:
> get { ... } set { ... }
>
> Should we do the same in Python:
>
> self.__privateAttr = 'some val'
>
> def getPrivateAttr(self):
> return self.__privateAttr
>
>
I've been thinking if there's a point in applying some specific OOP
techniques in Python as we do in other languages.
i.e. we usually define private properties and provide public functions
to access them, in the form of:
get { ... } set { ... }
Should we do the same in Pyt
17 matches
Mail list logo
