On Mon, 04 Oct 2010 09:51:18 -0700, Dennis Lee Bieber wrote:
> On 04 Oct 2010 05:08:20 GMT, Steven D'Aprano
> declaimed the following in
> gmane.comp.python.general:
>
>
>> from luncheon_meats import Ham
>>
>> class Spam(Ham):
>> def __init__(self):
>> self.__x = "yummy"
>>
>>
>>
On Sun, 03 Oct 2010 21:32:25 -0700, Dennis Lee Bieber wrote:
> Well... then use the double __ prefix so your instance variables
> have a class specific name... That IS what the __ are designed to do --
> ensure that the name, as used /in/ that class itself is unique, and not
> referencing so
In article <14cf8b45-a3c0-489f-8aa9-a75f0f326...@n3g2000yqb.googlegroups.com>
Rock wrote:
>I've really been wondering about the following lately. The question is
>this: if there are no (real) private or protected members in Python,
>how can you be sure, when inheriting from another class, that yo
On Mon, 04 Oct 2010 11:57:18 +1300, Gregory Ewing wrote:
> Rock wrote:
>> What if the
>> library I'm using doesn't realase the source, or what if I just can't
>> get my hands on it for some reason or another?
>
> You can always use dir() on an instance of the class to find out what
> names it's u
On Sun, 03 Oct 2010 15:04:17 -0700, Rock wrote:
> Thanks for the reply. No, I was just working with a normal library class
> which was supposed to be derived. So that's what I did, but in the
> process I found myself needing to create an instance variable and it
> dawned on me: "how do I know I'm
On Oct 3, 5:17 pm, MRAB wrote:
> On 04/10/2010 00:06, Steve Howell wrote:> On Oct 3, 3:57 pm, Gregory
> Ewing wrote:
> >> Rock wrote:
> >>> What if the
> >>> library I'm using doesn't realase the source, or what if I just can't
> >>> get my hands on it for some reason or another?
>
> >> You can
On Oct 3, 5:13 pm, Carl Banks wrote:
> On Oct 3, 3:04 pm, Rock wrote:
>
> > No, I was just working with a normal library
> > class which was supposed to be derived. So that's what I did, but in
> > the process I found myself needing to create an instance variable and
> > it dawned on me: "how do
On 04/10/2010 00:06, Steve Howell wrote:
On Oct 3, 3:57 pm, Gregory Ewing wrote:
Rock wrote:
What if the
library I'm using doesn't realase the source, or what if I just can't
get my hands on it for some reason or another?
You can always use dir() on an instance of the class to
find out what
On Oct 3, 3:04 pm, Rock wrote:
> No, I was just working with a normal library
> class which was supposed to be derived. So that's what I did, but in
> the process I found myself needing to create an instance variable and
> it dawned on me: "how do I know I'm not clobbering something
> here???" ...
Arnaud Delobelle writes:
> I've been reading c.l.python for years (on and off) and I can't recall
> anybody saying this has been a problem in practise.
It has been a problem for me at least once. I blew a good chunk of a
day debugging a problem that turned out due to my clobbering something
in
On Oct 3, 3:57 pm, Gregory Ewing wrote:
> Rock wrote:
> > What if the
> > library I'm using doesn't realase the source, or what if I just can't
> > get my hands on it for some reason or another?
>
> You can always use dir() on an instance of the class to
> find out what names it's using.
>
Indeed
Rock wrote:
What if the
library I'm using doesn't realase the source, or what if I just can't
get my hands on it for some reason or another?
You can always use dir() on an instance of the class to
find out what names it's using.
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 3, 3:04 pm, Rock wrote:
> > Object-oriented designs are difficult to design in any programming
> > language, and it helps to have some sort of concrete problem to drive
> > the discussion. Are you working on a particular design where you
> > think Python's philosophy will inhibit good desi
Arnaud Delobelle writes:
> I've been reading c.l.python for years (on and off) and I can't recall
> anybody saying this has been a problem in practise.
Arghh! Practice, I meant practice!
--
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list
Rock writes:
>> Object-oriented designs are difficult to design in any programming
>> language, and it helps to have some sort of concrete problem to drive
>> the discussion. Are you working on a particular design where you
>> think Python's philosophy will inhibit good design? My take on Pytho
> Object-oriented designs are difficult to design in any programming
> language, and it helps to have some sort of concrete problem to drive
> the discussion. Are you working on a particular design where you
> think Python's philosophy will inhibit good design? My take on Python
> is that it focu
On Oct 3, 1:07 pm, Rock wrote:
> Hi all :)
>
> I've really been wondering about the following lately. The question is
> this: if there are no (real) private or protected members in Python,
> how can you be sure, when inheriting from another class, that you
> won't wind up overriding, and possibly
On 10/03/2010 01:07 PM, Rock wrote:
Hi all :)
I've really been wondering about the following lately. The question is
this: if there are no (real) private or protected members in Python,
how can you be sure, when inheriting from another class, that you
won't wind up overriding, and possibly clobb
Hi all :)
I've really been wondering about the following lately. The question is
this: if there are no (real) private or protected members in Python,
how can you be sure, when inheriting from another class, that you
won't wind up overriding, and possibly clobbering some important data
field of the
19 matches
Mail list logo
