On 4/7/06, Eli Stevens (WG.c) <[EMAIL PROTECTED]> wrote: > I'm curious what effect overloaded functions will have on duck typing; a > Something can act like a list, but from my understanding of the > discussion* it won't end up matching: > > @pprint.register(list) > def pprint_list(obj): > pass
Right. Neither does it automatically pickled like a list, copy.py won't copy it as a list, etc. > It seems to me that now to get a duck-typed list, not only do you have > to implement all of special methods that define "listy-ness," you also > have to find the overloaded functions that are specialized for lists, > and register your own implementation (or an implementation specialized > for lists, if appropriate). Right. I can see some ways to make this less if an issue, but it won't go away completely: - you only have to add registrations to those overloaded functions that your application uses with this specific type of sequence - frameworks should probably build a layer of adaptation on top of overloaded functions, where you cast your object to their "sequence" interface before passing it in I believe Phillip Eby's PyProtocols solves this by letting you specify conditions including hasattr() instead of just type checks. > If a consumer of your listy class is also a consumer of some separate > overloaded functions that operate on lists, will they be responsible for > registering your listy class into the overloaded functions? How does > that work when the overloaded functions are an implementation detail of > the other library they happen to use? That's not going to work very well. > I think there's a lot of interesting potential here; but the reliance on > object type seems to imply that you can't mix it with duck typing, and > I'm not sure if that's being fully considered. A very good point. Probably "raw" overloading isn't enough; we'll still need to build a system of interfaces and adapters on top of them. It's just that building adapters out of overloading seems more elegant than having adaptation as the primitive operation. -- --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
