derived / base class name conflicts

[christopherlmarshall]

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

[Bruno Desthuilliers]

ch************* *****@yahoo.com a écrit :

Your suggestion ('_name' -> implementation, 'name' -> API)
This is not "my" convention, it's *the* (mostly agreed upon) Python
convention. Like 'self', or CONSTANT, or a whole lot of things in Python.
makes sense
as a convention between programmers that know a fair amount about each
other's classes before using them.
No need to know much. dir(modulename. ClassName) is enough.
I don't think it is reasonable in general to only subclass from base
classes you have studied the full API of, however.
Depends on your definition of "studying the full API" !-)

Now if your fear is to accidentally override something in the base
class, it's just a matter of:
print "API:"
print [name for name in dir(modulename. ClassName) \
if not name.startswith ('_')]

print "IMPLEMENTATION :"
print [name for name in dir(modulename. ClassName) \
if not name.startswith ('_')]
The double
underscore is a decent solution to my problem.
Possibly. It can also become a PITA. But it's you who know what your
code need !-)
I imagine it must be used a lot in domains where people are making
heavy use of third party python code.

I almost never used it (perhaps half-a-dozen times, and only in
frameworks abstract base classes), and rarely saw it in 3rd part source
code.

[Steven Bethard]

ch************* *****@yahoo.com wrote:

so the following would not result in any conflicts

class A:
def __init__(self):
self.__i= 0

class B(A):
def __init__(self):
A.__init__(self )
self.__i= 1

Be careful here. The above won't result in any conflicts, but related
cases, where you have two classes with the same name in different
modules, may still result in conflicts. See my previous posts on this:

http://groups.google.com/group/comp....3984abaee1c2b5
http://groups.google.com/group/comp....3183a2c01c8ecf

However, I tend not to use double-underscore name mangling, and I don't
think I've ever had a shadowing problem, so clearly I wouldn't have
shadowing problems with double-underscore name mangling either...

STeVe

[Steven Bethard]

ch************* *****@yahoo.com wrote:

so the following would not result in any conflicts

class A:
def __init__(self):
self.__i= 0

class B(A):
def __init__(self):
A.__init__(self )
self.__i= 1

Be careful here. The above won't result in any conflicts, but related
cases, where you have two classes with the same name in different
modules, may still result in conflicts. See my previous posts on this:

http://groups.google.com/group/comp....3984abaee1c2b5
http://groups.google.com/group/comp....3183a2c01c8ecf

However, I tend not to use double-underscore name mangling, and I don't
think I've ever had a shadowing problem, so clearly I wouldn't have
shadowing problems with double-underscore name mangling either...

STeVe