Method overloading?

[Paul McGuire]

On Feb 15, 12:23 am, Steven D'Aprano
<s... at REMOVEME.cybersource.com.au> wrote:
> On Wed, 14 Feb 2007 21:58:35 -0800, Paul McGuire wrote:
> > No, Python does not do overloading as part of the language, you have
> > to do the variable argument interpretation for yourself.
>
> > For instance, if you want a method to accept a single argument of
> > various types, it would look something like this:
>
> > def multiAccept( argOfVariousTypes ):
> >     if isinstance(argOfVariousTypes,int):
> >         # treat like an int
> >     elif isinstance(argOfVariousTypes,float):
> >         # treat like a float
> >     elif isinstance(argOfVariousTypes,(list,tuple)):
> >         # treat like a container
>
> Is that really called "overloading"? I've never (knowingly) come across
> the term being used in that context before. I've always known that as
> "multiple dispatch" or "polymorphism", depending on whether you or the
> compiler handles the dispatching.
>

Well, I think "overloading" and "Python" may not even belong in the
same sentence, actually.  "Overloading" is used in C++, Java and C# to
describe a single method name with multiple signatures.  It is not
really possible to implement such a thing in Python, which just binds
methods to names, and duplicate definitions of methodX just replace
the former with the latter.

But from the standpoint of the caller, calls to methodX() with various
numbers and types of arguments looks just the same as it does in Java
or C# with method overloading, and could reasonably be thought of as
such - what does the caller care how methodX handles these various
calls, whether with 1 hyper-adaptive method implementation or a dozen
type-specific ones?

I've had this discussion before, but I personally tend to reserve the
term "polymorphism" for instance-level behavior, such as when a
collection of instances that all derive from a common base class have
overridden method definitions.  The typical example is a list of
Shapes, each implementing its own draw() method, so that they
polymorphically do their subclass-appropriate draw behavior.  Or for a
Strategy pattern implementation (one of my favorite), where derived
strategy classes implement a base interface with their separate
behaviors, and each is accessed through the interface definition.

The beauty of Python's duck-typing is that this same kind of
polymorphism can be achieved without the burden of class inheritance
hierarchies.  As long as the instances referenced all implement
methodX(), Python is happy.  If I'm desperate, I could even
dynamically attach a do-nothing or default version of such a method if
it were not already defined for an instance.  Try *that* in C++
(without a horrifying haystack of angle brackets)!

I have heard "overloading" referred to as "method polymorphism", but I
think this is just a dilution of the "polymorphism" term, with no
additional knowledge transfer gained.

-- Paul