Overloading objects

[Tom Lee]

Chad Netzer wrote:

> 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')

Ah, cheers.

> 
> 
>>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.
> 

Along the same lines of the argument against isinstance right? Makes sense.

> 
>>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.
> 

Yeah, but by the same token it makes your methods a little easier to 
read. I agree, however.