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

Jim Jewett jimjjewett at gmail.com
Thu May 10 00:26:48 CEST 2007

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 do_stuff implementation for class C.

@before(do_stuff)
def debug_it(obj: ClassA):    # Never called, it is a classC

def debug_it(obj: not ClassA)   # can't do this?

def debug_it(obj):                # OK, trace *everything*.
    # Or, at least, everything that nicely did a call_next_method,
    # in case you wanted to wrap it this way.  Objects that thought
    # they were providing a complete concrete implementation will
    # still sneak through

def wrap_the_generic(generic_name, debug_it):
    orig = generic_name
    def replacement( ...)  # hope you get the .sig right
        debug_it(...)
        orig(...)
    generic_name = replacement   # hope you can monkeypatch
    # uhh ... was the original supposed to have additional behavior,
    # for more registrations, etc...

Unless I'm missing something, this only simplifies things when all specific implementations not only drink the kool-ade, but avoid kool-ade related bugs.

-jJ

More information about the Python-3000 mailing list