[Python-Dev] type categories
16 Aug 2002 14:28:48 +0100
Andrew Koenig <firstname.lastname@example.org> writes:
> ark> It makes me uneasy because the behavior of programs might depend
> ark> on the order in which modules are loaded. That's why I didn't
> ark> suggest a way of defining the variations on f in separate places.
> David> This concern seems most un-pythonic to my eye, since there are
> David> already all kinds of ways any module can change the behavior of
> David> any call in another module. The moset direct way is by
> David> rebinding the implementation of another module's
> David> function. Python is a dynamic language, and that is usually
> David> seen as a strength.
> Indeed. What concerns me is not dynamic behavior, but order-dependent
> behavior that might be occurring behind the scenes. I would really like
> to be confident that if I write
> import x, y
> it has the same effect as
> import y, x
> I understand that there is no guarantee of that property now, but I suspect
> that most people write programs in a way that does guarantee it. I would
> hate to see the language evolve in ways that makes it substantially more
> difficult to avoid such order dependencies, so I am reluctant to propose
> a feature that would increase that difficulty.
I may be getting lost in subthreads here, but are we still talking
about multimethods? If we are, then surely any sane multimethod
system's method resolution has to be independent of the order of
method definition. There are ways of doing this.
An implementation along the lines of:
def match(args, spec):
for a, t in zip(args, spec):
if not isinstance(a, t):
self.methods = 
def add(self, f, typespec):
def __call__(self, *args):
for meth, typespec in self.methods:
if match(args, typespec):
is just insane.
If I've missed the source of concern, I'm sorry...
incidentally, asking why things are "left out of the language" is
a good sign that the asker is fairly clueless.
-- Erik Naggum, comp.lang.lisp