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 functions
> to access th
[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
>
>
16 matches
Mail list logo
