Method Overloading

Alex Martelli aleaxit at yahoo.com
Wed Aug 30 05:29:38 EDT 2000


"Nicholas Routledge" <n.routledge at bigpond.com> wrote in message
news:Z%2r5.40631$c5.112963 at newsfeeds.bigpond.com...
> Hi,
>
> Just wondering whether Python supports Method Overloading like in Java.
> That is, multiple declarations of the same name method with different
> arguements for each one.

No.  A method's name univocally identifies it in Python.  The method
can, of course, receive different types and numbers of arguments, and/or
named-arguments (also known as keyword-arguments), and perform whatever
variations on its functionality are required.

Let's exemplify the variation in approach that this requires.

Say that we want a method fileChecksum that will take an open file, read
its contents, and return a checksum of them.  As a convenience to client
code, we want to let them call fileChecksum with a string instead of an
open file: the overloaded method accepting a string will try to use it
as the filename, open the file, and delegate the rest of the work to the
other overloaded version, the one accepting the already-open file.  This
is a typical example where overloading is used in Java (or C++). [Assume,
to let us focus on relevant issues, that we have a separate dataChecksum
method already, that will take a blob of data and return its checksum;
so the problem here boils down to obtaining the blob given either the
open-file or the filename-to-open].

In Python, we would have a single fileChecksum method (or function, if
there is no special object to which we naturally want to ask for such
checksums; Python doesn't force you to cast every functionality into
pseudo-object-oriented terms whether you want to or not -- it lets you
express as O-O exactly those functions for which that makes sense).

That method can simply check if the argument is a file object, or a
reasonable imitation thereof -- any object that implements a read()
method.  If it isn't, then the open() can be tried.  On the usual
"it's better to ask forgiveness than permission" paradigm (try an
operation and catch/handle possible exceptions, rather than checking
beforehand; Python lets you do the checking, too, when that makes
more sense, but try/except is often handy):

def fileChecksum(file):
    try:
        data=file.read()
    except AttributeError:
        data=open(file,'r').read()
    return dataChecksum(data)

This is normally better than explicit typechecking with the
type() built-in function, because it makes it easier to use
the function with work-alike objects as arguments.  But, if
you prefer, you could recast this to say "if it's a string
then use it as a filename to open, else it must be a file or
file-like object [i.e., have a read method]":

def fileChecksum(file):
    if type(file)==type(''):
        file=open(file,'r')
    return dataChecksum(file.read())


In either case, the 'runtime dispatching' approach (whether
through try/except, or type-tests) is at least an adequate
alternative to "overloading", an approach which is more
suitable for statically-typed languages such as Java or C++
than for dynamically-typed ones such as Python.


For some cases in which you might use overloading in Java,
in Python, as in C++, you will use default-valued arguments
instead.  Typical is when a method has (say) one mandatory
argument, a string, and another (say) one which may or may
not be present -- if it isn't, i.e. the 1-argument version
is called, this is equivalent to calling the 2-argument
version with a second argument worth "foo".  In Java, you
might write two overloads, delegating to amethod(bar, "foo")
when the one-argument overload of amethod is called.  In
Python, as in C++, giving the 2nd argument a default is
often preferred:

def amethod(bar, foo="foo"):
    return 'whatever'+str(bar)+str(foo)

amethod doesn't care if it's being called with one or two
actual arguments; if only one, the second one is provided
anyway, with its default-value.  This is often a very direct,
clear, and explicit way of expressing things.


Alex






More information about the Python-list mailing list