[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
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(do_stuff)
> > def debug_it(ob: ClassC):
> > import pdb
> > pdb.set_trace()
> > 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
> > do_stuff and ClassC from, and put the above in a module that's been
> > imported when do_stuff 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