On 12/1/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 11:52 AM 12/1/2006 -0800, Bill Janssen wrote: > >Paul Moore writes: > > > There is no expectation that all/most (or even > > > many!) libraries would be based on ABCs. Duck typing would remain the > > > norm. Although I'm not clear what the value of all this is, if the > > > resulting ABCs *don't* get used in real code. > > > >I'm not sure what it means to base a library on ABCs. You base types > >on ABCs. > > > >But I'd hope that more library implementors would shift to documenting > >required interfaces for parameters where appropriate, rather than the > >current practice of either (1) not specifying anything, and forcing a > >caller to read the code, or (2) spotty and incomplete documentation of > >required methods, forcing smart callers to read the code. And lots of > >library implementors don't know what methods are required if you need > >a value to support the "[k]" operation. I would hope that eventually, > >for most widely used library packages, duck typing would *not* be the > >norm, because I think it's a source of both fragility and FUD in the > >Python world. > > I would actually hope that library implementors would shift to using > generic functions, since then they can just document what the function(s) > are supposed to do, and people can just add methods to those functions for > any object types they like, without needing to subclass anything, or have > to deal with "interfaces" at all.
I'm not sure what you mean this. Are you proposing that a library function that might take a mapping would be rewritten as a generic library function with one implementation that takes a mapping? Or are you proposing that the library function, instead of documenting that it takes a mapping, documents which generic functions should be applied to it? Both sound like rather a big stretch from current practice. > In other words, I just want to use my object with some operations that a > library provides (or requires). An "interface" is excise: something I have > to mess with that doesn't directly relate to my goals for using the library. I don't understand the sentence "An "interface" is excise". What does excise mean in this context? Regardless, I find it quite a big change from various ways of saying "this object must have these methods (including perhaps some for which special syntax exists, like __getattr__)" to saying "this object must be supported by these generic functions". A method is just an identifier in the object's attribute namespace. A generic function is an object that may hve to be imported from elsewhere. This may make sense in CLOS (if I understand the summary Bill gave me over lunch Monday correctly) but is quite different from current practice in Python. > Generic functions are type-safe duck typing because ducklib.quack(ob) > doesn't rely on ob having a 'quack()' method that means what you think it > means. This solves the problem simply and directly, without introducing > interfaces and ABCs and whatnot. Either the operation is defined for the > type or it isn't. I object to the suggestion that seems to be implied here that in the future we'll all be writing ducklib.quack(ob) instead of the much simpler ob.quack(). I really like that when I have an object in my hands, I don't need to import anything else in order to manipulate it, as long as the manipulation can be done through methods. I also don't think that the homonym problem that you (and CLOS) are trying to solve here is all that important in practice. For the one homonym that is relevant in practice (__getitem__ ipmlemented by sequences and mappings alike, but with very different invariants) I think I prefer Bill's ABC solution or an interfaces-based solution over a GF-based solution, because the ABC and the interface address the issue that there are invariants *across* operations. (E.g. x in d equals x in d.keys(), len(d) == len(d.keys(), d.items() == zip(d.keys(), d.values(), and and many more.) So knowing that something is an instance of a Mapping ABC or interface vs. a Sequence ditto conveys more information than knowing that it implements __getitem__(). You could probably address this somewhat by having two different oeprations, Mapping.__getitem__ and Sequence.__getitem__, but that doesn't change the fact that the normal spelling is x[y] in both cases, and it doesn't do much about the relationships between different operations either. (Did you see the example I posted about a week ago sketching an ABC or interface hierarchy for sets? That strongly exemplified IMO the need to be able to talk about a group of operations together with some invariants, rather than just a bunch of operations.) > At most, an interface need only specify what operations must be defined for > a type, in order to allow it to be used for a different operation. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
