[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.

[Phillip J. Eby]

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.