[With apologies for having a monologue with myself here.] On 11/24/06, I wrote: > I'd like to take the opportunity to present another example of what > I'd like to be able to do with abilities and generic functions. [...]
Thinking about my own example some more, I think it would actually work just as well using ABCs instead of abilities. (The GFs are still needed.) It seems the use case for making abilities/interfaces separate from ABCs hinges on the assumption that there are classes that implement certain protocols without realizing it, IOW emergent protocols, plus that it's not practical to change __bases__. This seems to be exacerbated by there not being any standard abilities/interfaces defined, while some of the standard types are just *begging* to be classified by a container hierarchy. Plus, the standard types won't let you alter their __bases__ at all. I wonder if a bunch of well thought-out standard ABCs, applied to the standard data types, and perhaps more support for setting __bases__, wouldn't address most concerns. Note: I still like GFs for operations, especially binary operators, because they solve the problem of two-sided dispatch much better than __add__ and __radd__ ever can. (For unary operators I'm not sure it buys us that much; I'm pretty happy with __len__ and __iter__.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
