derived / base class name conflicts

[Steve Juranich]

This should prove most enlightening:

import Tkinter
dir(Tkinter.Canvas)



On 10 Nov 2005 14:53:04 -0800, christopherlmarshall at yahoo.com
<christopherlmarshall at yahoo.com> wrote:
> Suppose you want to write a subclass of some existing class you are
> importing from a module you didn't write and that you don't want to
> study the internals of, and you want to define a data member i in your
> constructor.
>
> As in the following:
>
> from module1 import A
>
> class B(A):
>    def __init__(self):
>       A.__init__(self)
>       self.i= 0
> b= B()
>
> Now, 'i' might have already been defined by A or by the call to
> A.__init__() so if you define it without knowing that, you could be
> changing the behavior of A's methods in unknown ways, which is
> obviously a bad thing.
>
> One way to avoid this is to run the following program to clear the name
> 'i' first:
>
> from module1 import A
> a= A()
> print a.i
>
> If you get an AttributeError, you know the name 'i' is safe to use.  If
> you actually get some sort of report from the print statement, then you
> will know that 'i' is not safe to use.
>
> This strikes me as a rather odd procedure to go through, but I don't
> see any way around it.
>
> It there some other way to handle this issue?
>
> Do I actually need to study the sources for / implementation of
> Tkinter.Canvas before I can safely subclass it (and assign attributes
> to an instance of the subclass) or clear attribute names as I outlined
> above?
>
> Chris Marshall
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>


--
Steve Juranich
Tucson, AZ
USA