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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: derived / base class name conflicts

[christopherlmarshall]

Steve Juranich wrote:
> This should prove most enlightening:
> 
> import Tkinter
> dir(Tkinter.Canvas)
> 
> 

Huh?

Chris Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: derived / base class name conflicts

[christopherlmarshall]

Fredrik Lundh wrote:
> [EMAIL PROTECTED] wrote:
>
> > 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.
>
> http://docs.python.org/tut/node11.html#SECTION001160
>
> 

I see.  Thanks for the link.

So putting two underscores in front of an instance variable (or any
identifier used inside the scope of a class statement) invokes a name
mangling mechanism ( __x becomes __classname_x internally)

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

Is it commonplace to use underscores when defining derived class
instance variables, or is this considered against the grain of python?

Chris Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: derived / base class name conflicts

[christopherlmarshall]

I see what you mean now.

It would indeed be enlightening if I wanted to study the internals of
Tkinter, and perhaps one day I will.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: derived / base class name conflicts

[christopherlmarshall]

Your suggestion ('_name' -> implementation, 'name' -> API) makes sense
as a convention between programmers that know a fair amount about each
other's classes before using them.

I don't think it is reasonable in general to only subclass from base
classes you have studied the full API of, however.  The double
underscore is a decent solution to my problem.

I imagine  it must be used a lot in domains where people are making
heavy use of third party python code.

Chris Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: testing C code with python

[christopherlmarshall]

I have recently started using tcl to do this with C++ code and will
soon be switching to doing it with python.

I think it is a fantastic way to arrange to test C++ and C code.
Python makes an excellent test-harness, and writing interfaces for
complex units of C++ code to enable them to be tested from Python is an
valuable exercise in itself.  It forces you to make your code
inspectable and brings up all sorts of important design issues that
otherwise would never occur to you.

It was a lot of work to get started with this but once you put in the
initial effort, it gets eaiser to maintiain.  And the payoff is that it
lets you write regression tests easily so that would be too hard to do
otherwise.

-- 
http://mail.python.org/mailman/listinfo/python-list