[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc. (original) (raw)

BJörn Lindqvist bjourne at gmail.com
Thu May 10 12:40:13 CEST 2007

On 5/10/07, Jim Jewett <jimjjewett at gmail.com> wrote:

On 5/9/07, Phillip J. Eby <pje at telecommunity.com> wrote: > At 09:54 PM 5/9/2007 +0200, BJörn Lindqvist wrote:

> >What if they have defined a dostuff that dispatch on ClassC that is a > >subclass of ClassA? Good luck in figuring out what the code does. > >With the non-overloaded version you also have the ability to insert > >debug print statements to figure out what happens. > @before(dostuff) > def debugit(ob: ClassC): > import pdb > pdb.settrace() I think this may be backwards from his question. As I read it, you know about class A, but have never heard about class C (which happens to be a substitute for A). Someone added a different dostuff implementation for class C.

It is backwards, using the debugger solves a problem that should not have been there in the first case. Let's assume the original flatten example again:

from overloading import overload
from collections import Iterable

def flatten(ob):
    """Flatten an object to its component iterables"""
    yield ob

@overload
def flatten(ob: Iterable):
    for o in ob:
        for ob in flatten(o):
            yield ob

@overload
def flatten(ob: basestring):
    yield ob

Let's also assume that:

  1. The above code is stored in a file flatten.py.

  2. There is a class MyString in file mystring.py which is an Iterable but which is not a basestring.

  3. There is a third file foo.py which contains

    RuleSet(flatten).copy_rules((basestring,), (MyString,))

  4. There is a fourth file, bar.py, which contains

    ms = MyString('hello') print list(flatten(ms))

  5. These four files are part of a moderately large Python project containing 80 modules.

According to how Phillip has described PEAK-style generic functions, these assumptions are not at all unreasonable.

I am a new programmer analyzing the code on that project. I have read the files flatten.py, mystring.py and bar.py but not foo.py. The snippet in bar.py is then very surprising to me because it will print ['hello'] instead of ['h', 'e', 'l', 'l', 'o'].

Using a simple dispatch technique like the one in my handle_tok example, or in the non-generic version of flatten, I wouldn't have this problem. Now I do, so how do I troubleshoot it?

I could use the debug_it @before-function, but I don't think I should have to just to see the control flow of a darn flatten function. The other approach would be to grep the whole source for "flatten." Then I should be able to figure out which dispatch rules are active when the snippet in bar.py is invoked. But it would require considerable work.

-- mvh Björn

More information about the Python-3000 mailing list