Re: Some suggestion for python classes

Jaap Vermeulen (jaap@sequent.com)
Mon, 10 May 1993 15:22:44 -0700

| Ah, but calling a class method is also used in another situation. The
| standard "idiom" for extending a method is as follows:
|
| class Base:
| def doit(self, how):
| "do it in a basic way"
|
| class Derived(Base):
| def doit(self, how):
| "do a little bit in advance"
| Base.doit(self, how)
| "do it some more"
|
| For the interpreter, the call to Base.doit(self, how) in a method of a
| Derived instance is indistinguishable from a call somewhere else.

And that exactly illustrates the deficiency for not having a "super"
operator (I'm jumping ahead to the next issue here), and that is that
with multiple base classes you have to choose (or *know*) which base
class to invoke (or write a loop to go through all of them). That's
why I prefer a "super" functionality where you let the search algorithm
find the method (i.e. it would be nice if I could rewrite the above with):

def doit(self, how):
"do a little but in advance"
self^doit(how)
"do it some more"

I never liked the fact that you have to spell out the base class you're
invoking from.

| But maybe your example is too simplistic to show what the real problem
| is. What does your new() function do between creating the new
| instance and returning it? Can't this be done by the instance's
| init() function?

You convinced me that I don't need this functionality.

[About the "super" operator:]

| See my example above of how to extend a method in Python. The point
| is that the name of the base class is statically known at the point
| where you write the code that needs to use it, so there really is no
| good reason to dynamically look it up -- you might as well use the
| name of the base class.

Not with multiple base classes. Besides, you're looking it up
dynamically anyways (since the method could be way up in the chain).

| You don't give an implementation of your super() workaround -- I have
| a feeling that it might fail if there are several layers of derived
| classes stacked on top of bar and some of them don't define a new()
| method.

I don't think so:

def super(obj, name):
if type(obj) == type(object): sym = 'obj.'+name
else: sym = 'obj.__class__.'+name

try:
try:
func = eval(sym)
exec('del '+sym)
return eval('obj.'+name)
finally: exec(sym+'=func')
except: return eval('obj.'+name)

[About aClass.__name__:]

| I don't understand how you want it to work. Do you mean that a class
| should be able to decide how it will be printed? How would you use
| that? How would you distinguish between the __repr__ method for
| instances and the one for the class?

Let me rephrase this: Currently what the repr() prints out is of
little use to see what it is. It would be *much* nicer, and of much
more use if the name could be included in the default representation,
both for classes and instances.

-Jaap-

--
Jaap Vermeulen					+--------------------------+
						| Sequent Computer Systems |
	Internet : jaap@sequent.com		| Beaverton, Oregon	   |
	Uucp	 : ...uunet!sequent!jaap	+--------------------------+