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

Phillip J. Eby pje at telecommunity.com
Thu May 10 03:23:41 CEST 2007

At 06:26 PM 5/9/2007 -0400, Jim Jewett 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. @before(dostuff) def debugit(obj: ClassA): # Never called, it is a classC

Actually, if you read what was said above, ClassC is a subclass of ClassA, so the above is called.

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

Actually, you can, if you create something like a NotClass type and register methods to define its implication relationships to classes and other criteria. Of course, it then wouldn't be called for ClassC...

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

Which is an excellent demonstration, by the way, of another reason why before/after methods are useful. They're all always called before and after the primary methods, regardless of how many of them were registered.

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

I don't understand what this last example is supposed to be, but note that if you want to create special @debug methods with higher precedence than Around methods, it's relatively simple:

class Debug(Around):
    """Like an Around, but with higher precedence"""

debug = Debug.make_decorator('debug')
always_overrides(Debug, Around)
always_overrides(Debug, Method)
always_overrides(Debug, Before)
always_overrides(Debug, After)

(It occurs to me that although the current prototype implementation requires you to explicitly declare method override relationships for all applicable types, I should probably make the transitive declaration(s) automatic, so that the above would require only 'always_overrides(Debug, Around)' to work.)

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.

I don't understand what you mean here.

More information about the Python-3000 mailing list