On Feb 15, 12:23 am, Steven D'Aprano <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
