Overloading objects

Chad Netzer cnetzer at sonic.net
Tue Sep 2 07:20:38 EDT 2003


On Tue, 2003-09-02 at 02:58, Tom Lee wrote:
> Batista, Facundo wrote:

> > I thought using defaults:
> > 
> > def myMethod (self, name, age=None):
> >         self.name = name
> >         if age not None:
> >                 self.age = age
> > 
> > 
> > but I'm concerned about the scalability of this.

In general, it isn't a problem.  You really don't want methods with LOTS
of arguments.  If you need variable numbers of arguments, where the
default value system doesn't help you, just use *args, and do things
positionally by counting the length of the argument list.

In Python, you can always use argument keywords when you call your
method, so you don't need to remember the positions.  Learn to rely on
keyword arguments, and your life with Python will be happier.

Also, you can use a dictionary to hold and pass your arguments around
easily, and can have it automatically substitute the keyword values when
you call the function (using **kwds).  If you need LOTS of arguments,
use a dictionary or class, and pass THAT to your method.

> > What's the most pythonic way to do this? Using something like *args or 
> > **args?

Yes.  It is easy and powerful once you see some examples.


[Tom Lee]
> Scalability doesn't even come into this question - if you're really 
> worried about performance, don't use Python.

I assume the original poster was concerned with the scaling of the
number of arguments, and it becoming unmanagable to use and maintain. 
Not anything to do with speed (ie. a different kind of 'scaling')

> Anyway, you have two or three choices:
> 
> 1. Do it the way you're doing it.
yep.

> 2. Check parameter types at runtime using type() and the is keyword. e.g.
> if type( somevar ) is int:
>    self.do_int_stuff( somevar )
> else:
>    self.do_other_stuff( somevar )

Rather than doing explicit type checks, it is somehat more robust to try
to operate on the argument as if it were a valid type, and be prepared
to handle exceptions.  Only coerce to another to another type when you
need to:

try:
    self.do_int_stuff( int( some_int_like_var ) )
except TypeError:
    [handle the other cases or error]

If you do want to have set types (as one often does), try to test based
on behavior, since many objects can act similarly and interact together,
without being the same type (and so type checking will always be overly
restrictive and reduce the utility of your design)

Anyway, it is a tangential, and somewhat more advanced topic than this
thread was started to cover.

> 3. Use similar names for similar methods. wxPython does this. e.g.

yep.  Although that's not my favorite design.  Just makes it harder to
learn things by introspection (requires more reference manual searching
than using fewer methods with more option arguments, (IMO))  It's a
tricky balance, sometimes.

-- 
Chad Netzer






More information about the Python-list mailing list