[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.

[Jim Jewett]

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 do_stuff 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(do_stuff)
>      def debug_it(ob: ClassC):
>          import pdb
>          pdb.set_trace()

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