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. _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
