[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
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 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.
> def debug_it(ob: ClassC):
> import pdb
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.
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
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.
More information about the Python-3000