[Python-Dev] type categories

[Michael Hudson]

Greg Ewing <greg@cosc.canterbury.ac.nz> writes:

> As long as all the implementations have to be in one place,
> this is equivalent to
> 
>   def f(a):
>     if belongstocategory(a, Cat1):
>       ...
>     elif belongstocategory(a, Cat2):
>       ...
>     elif belongstocategory(a, Cat3):
>       ...
> 
> so you're not gaining much from the new syntax.

Good point.

> > It might also be possible to modify a multimethod dynamically,
> > e.g. later one could write:
> > 
> >   def f4(a: Cat4):
> >     ...code for Cat4...
> > 
> >   f.add(f4)
> 
> This sort of scheme makes me uneasy, because it means that any module
> can change the behaviour of any call of f() in any other
> module.

True, but I don't think this is a problem in practice with CLOS is it?

I mean, you can currently do

import mod

mod.func = my_func # evil cackle!

but you don't.

> Currently, if you know the types involved in a method call,
> you can fairly easily track down in the source which piece of code
> will be called. With this sort of generic function, that will no
> longer be possible. 

I would sincerely hope that any core implementation of such an idea
would be introspective enough to allow finding method implementations.
Obviously this would only work at run time, but it would be a help
(imagine running under pdb).

Cheers,
M.

-- 
  Well, yes.  I don't think I'd put something like "penchant for anal
  play" and "able to wield a buttplug" in a CV unless it was relevant
  to the gig being applied for...
                                 -- Matt McLeod, alt.sysadmin.recovery