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

Phillip J. Eby pje at telecommunity.com
Wed May 9 23:44:02 CEST 2007

At 07:09 AM 5/10/2007 +1000, Nick Coghlan wrote:

Phillip J. Eby wrote: > At 09:54 PM 5/9/2007 +0200, BJörn Lindqvist wrote: >> With the non-overloaded version you also have the ability to insert >> debug print statements to figure out what happens. > > Ahem. > > @before(dostuff) > def debugit(ob: ClassC): > import pdb > pdb.settrace() > > Note that you don't even need to know what module the behavior you're > looking for is even in; you only need to know where to import > dostuff and ClassC from, and put the above in a module that's been > imported when dostuff is called. > > In other words, generic functions massively increase your ability to > trace specific execution paths.

Possibly another good example to include in the PEP...

Probably. When I write PEP's I tend to assume my primary audience is Guido, and I know he's already seen tons of tracing/logging/debugging/contract checking examples of what you can do with AOP. Or at least, I know he's previously mentioned being unimpressed by such. In any case, I didn't want to use that sort of example for fear that some might write the entire thing off as being more "unconvincing examples of AOP".

Still, it is kind of handy that you can write all your contract checking and debug/trace/log code in separate modules from your main code, and simply import those modules to activate those features. It's just not the only reason or even the most important reason to have generic functions.

More information about the Python-3000 mailing list