Kay Schluehr <[EMAIL PROTECTED]> wrote: ... > > typeclass mapping: > > def __getitem__(self, key): > > _notthere=[] > > result = self.get(key, _notthere) > > if result is notthere: raise KeyError > > return result > > def get(self, key, default): > > try: return self[key] > > except KeyError: return default > > # etc etc ... > I don't see why your typeclass illustration does not apply to ABCs as
Because in a class, A or B or not, this code WOULD mean mutual recursion (and it can't be checked whether recursion terminates, in general). In a typeclass, it means something very different -- a dependency loop. It's easy to check that all loops are broken (just as easy to check that all purely abstract methods are implemented) in an adaptation. > well? The sanity checks for typeclasses you describe seem to be a > particular feature of Haskell or other pure functional languages > without destructive updates and messy aliasing problems. It's hardly > believable that this would be possible in Python and runtime checks > won't help much in this case. Checks would happen at adapter-registration time, which is runtime: but so is the time at which a 'class' or 'def' statement executes, of course. Little but syntax-checks happens at compile-time in Python. Nevertheless the checks would help enormously, and I don't see why you would think otherwise. Prototypes of this (a metaclass performing the checks upon inheritance, i.e. non-abstract-subclass creation, but that's the same algorithm that could be run at adapter registration time if we got rid of the requirement of inheritance in favor of adaptation) have been posted to this group years ago. If a programmer does weird dynamic things to a type or an adapter after the checks, fine, they'll get exceptions if they later try to call (directly or indirectly) some method that's disappeared, or the like, just like they would with ABC's, interfaces, inheritance, or whatever else -- very few types are dynamically altered in this way in most production programs, anyway, so I won't lose any sleep over that possibility. > By the way I also don't understand Guidos concerns. Maybe he is against > the whole idea of creating frameworks and partial implementations? It's > not very clear for what reasons he likes interfaces. Just read his blog on artima -- and maybe, if something there is unclear to you, comment about it to see if you can get him interested in explaining better. Alex -- http://mail.python.org/mailman/listinfo/python-list
