using super

iu2 israelu at elbit.co.il
Tue Jan 1 01:56:41 EST 2008


On Dec 31 2007, 6:03 pm, Scott David Daniels <Scott.Dani... at Acm.Org>
wrote:
> As to the original idea, better to give it up.
> Typically code for a "chained" method "foo" that
> returns a result will want to (in some way) use
> the result from that call in forming its result.
> Python's super allows you to place that call where
> it belongs in your code (perhaps after some logging
> is enabled, for example) and not just "at the spot
> the guru insists the chaining happens."  

Indeed I might want to chain methods in all sort of ways:
@chain_call_before - call the parent's method before the derived
method
@chain_call_after - call the parent's method after the derived method
@chain_call_sum - sum the result of the parent's method with the
result of the derived method
@chain_call_list - make a list from the result of the parent's method
and the result of the derived method

An API for easily adding chaining methods is also something to think
about.
This kind of chaining actually exists in Common Lisp (CLOS) and I wish
for something like that in Python
so I gave it a(n unsuccessful) try.

I think that especially Python, which is known (among other things)
for its object oriented properties,
should support this kind of chaining.


>simply remind people to call
> A.foo(self, <args>) within the definition of foo in
> B.

Sorry, I can't agree to this (although there is nothing else I can
do.. :-) . Reminding is not "simply" at all. Why REMIND people do
stuff and not let Python handle it automatically? What's Python (and
all other powerful languages) for if not for this kind of job?
(Although I think this "chaining" is not supperted by none of them
except for Lisp).

Although I actually work in a C++ team, and all the Python I do is for
myself so I don't have to remind anyone, I think this mechansim is
necessary.
What actually made me intereseted in that is a C++ application I write
where I figured that
chaining would help.

If I translate it to Python, it's something like this:
(I'm still not familiar with new style classes so please forgive me..)

class Inetrface_system:
  def get_name(self):
    return "No_name"

get_name is an interface function which the programmer calls in the
application.
This is a new system:
class System_A(Interface_system):
  def get_name(self):
    return "System_A"

There are several dereived classes like System_A.
I need to log each call to get_name for any class, but I just can't
rely on remembering
(by progammers) to add this extra themselves for get_name for each
class they derive:

class Inetrface_system:
  def get_name(self):
    log_to_file('get_name called')
    return "No_name"

class System_A(Interface_system):
  def get_name(self):
    Interface_system.get_name()  # can be forgotten
    return "System_A"

One solution is:

class Interface_system():
  def get_name_api(self):
    log_to_file('get name called')
    return get_name()
  def get_name(self):
    return 'No name'

class System_A(Interface_system):
  def get_name(self):
    return 'System_A'

So programmers need only override get_name. But this makes it
confusing: One has to override
get_name, but must call get_name_api throughout the application. I
don't like it.
So, recalling CLOS I thought of a better way:


class Inetrface_system:
  @cained_call_before
  def get_name(self):
     log_to_file('get_name called')

@chained
class System_A(Interface_system):
  def get_name(self):
    return 'System_A'

Now the programmer both overrides get_name, and calls get_name
directly in the application. And
no one has to remember to call the parent's get_name method. It's done
automatically.

(A PEP maybe? I sense you don't really like it.. ;-)
What do you think? Good? Too implicit?

iu2



More information about the Python-list mailing list