Guido van Rossum wrote: > On 4/8/06, Talin <[EMAIL PROTECTED]> wrote: > >>You know, on the one hand, I've been reading this thread, and I'm >>excited about the possibility of generic functions (dynamic dispatch, >>duckaplex-typing, whatever you want to call it), but at the same time >>I kind of wonder about the eventual effect on the language. >> >>For example, it seems to me that most of the various magic methods, >>such as __cmp__, __add__, etc. would be better done with generics, >>especially since it gives you much finer control over the type of >>the other argument. So instead of having to write: >> >>class X: >> def __cmp__( self, other ): >> if isinstance( other, X ): >> return cmp( self.something, other.something ) >> return NotImplemented # or raise TypeError or whatever >> >>Instead you can just write: >> >>@generic( X, X ) >>cmp( a, b ): >> return cmp( a.something, b.something ) >> >>Similarly, if you add an integer to a string, the overloading machinery >>will report the error, instead of having to check it manually in the __add__ >>method. >> >>The addition of a funamentally new method of control flow - especially >>one that is a superset of an existing control flow method - is >>something that could potentially ripple through all of the standard >>libraries, transforming them beyond recognition. Given the obvious >>advantages, it would be hard to justify sticking with the older methods >>of doing things. >> >>While that's cool and I would look forward to working with them, I >>recognize that there are some downsides. >> >>For one thing, if generic functions are used in a way that truly leverages >>their potential, the structure of the code is going to be so different from >>2.x that there won't be any possibility of automated migration - unless >>you decide up front that the use of generics is going to be restrained and >>controlled, at least initially. >> >>Personally I'm fine with breaking from the past. But I wanted to point >>out what some of the potential consequences would be. > > > Right. I don't want to overdo it; I was thinking of making overloading > available to frameworks that need it, by importing it from some > library module, but not trying to use it for all those things for > which we already have working solutions (like binary operators). > > Last night I looked into using overloading to replace the mess that is > pickle. Unfortunately, an immediate problem is that overloading (at > least my current implementation, and also e.g. Phillip Eby's dynamic > dispatch code; and I believe also adaptation) is based on subclassing.
This is reason that I factored the signatures method out in my version of Protocol. With that factoring, it's a simple matter of replacing the signatures method with one that returns [type(x)] instead of x.__class__.__mro__. In one sense that may not gain you much over some custom decorators and a dictionary, but having a common interface for this sort of thing seems useful even if the implementation is not always shared. However, it's not clear to me at the moment how the signatures thing fits in with the generic function implementation where the resolution method is more complicated. It may turn out that the correct factoring is just into __call__ and find_func as you have. That would mean that things like pickle would need to override find_func with something trivial. > However, pickle is very careful not to use the same code for pickling > subclasses -- because (at least for primitive types like int) the > pickled representation is so efficient that it has no way to represent > the subclass information (even if it's only a class name). The pickle > module could use a style overhaul to use decorators, but I don't think > it should giveup its own registry mapping types to methods. I thought the point of distributed protocols / generics was that each module could have it's own (or several should it so choose). Why would it be a problem for pickles registry to use a Protocol subclass as it's registry? The main thing you'd gain is an interface in common with other clients of Protocol, but that's no small thing. > I suspect many other current uses of dispatch dictionaries (copy_reg, > for example) will have similar issues. Regards, -tim _______________________________________________ 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
