-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 12, 2007, at 7:40 PM, Phillip J. Eby wrote:
> Remember, len(), iter(), and suchlike are all generic functions -- > that just happen to be implemented using reserved method names > instead of a method registry. Do we need an ILengthMeasurable > interface to indicate that you can call len() on something? Or > does it suffice to say, "objects passed to this API need to be len > ()-compatible"? No, and yes. :) Okay, for stuff like this I agree that something like simplegenerics is a nice solution. But I'm having a hard time generalizing from a simplegenerics approach to the use cases where I (still) want to use interfaces. For example, what do you do if you want to talk about 8 attributes and a dozen methods as a cohesive unit. Let's say I want to allow people to implement an IUser which has an email address, a realname, a company, a reference to an IProfile, and let's me do thing like email them, remove them, subscribe them to a list, etc. In a generics approach, where do I document all this? > Finally, I posted here several months ago a short "Interface" class > that used generic functions for its base - it would let you define > generic functions in its body and then do Zope/PyProtocols-style > 'IFoo(bar).foo()' operations instead of 'foo(bar)'. It was, I > believe, only another 30-40 lines of code. > > Unless you want all of the fancy introspection features of > zope.interface (which I personally think tempt less-experienced > people to write code that will bite extenders in the butt) or the > exotic meta-features of PyProtocols (which I have found can be > replaced by generic functions with "method combination" support), a > few hundred lines of code should be more than sufficient to > implement both generic functions *and* interfaces for the stdlib's > needs. Generics seem like a good approach for "built-in" Python functionality, like len()-able, or file-like, or map-ish, where there's only one or two methods (or attributes) that contribute to the thing-ness you're trying to model. But for more complex and complicated interfaces, ISTM you need more elaborate mechanisms to document, declare, and verify compliance. The things I want something like zope.interfaces for is a way to put all the documentation about the contract between my stuff and your stuff in one place. I want a way for you to declare "here's an object that conforms to your contract" and I want a way to find all your objects that conform to my contract. Generally, I'm not concerned with whether you're lying or not, although in a debug or development mode, IWBNI you could turn on assertions or whatnot to verify these things (or perhaps have a lint-like mode that trolled through the code to do such verification). So a simplified Interface class might be just the trick for the majority of these use cases. Again, I'm mostly concerned with documentation, rather than strict enforcement or introspection. > (Btw, when I say that introspection produces butt-biting code, I > mean that when *I* first started using zope.interface, I created > all sorts of horrors until I realized that interface introspection > is an attractive but unnecessary evil, directly analagous to LBYL > vs EAFP and type-testing vs. duck-typing issues. See e.g.: http:// > www.mockobjects.com/2006/10/tell-dont-ask-and-mock-objects.html and > http://peak.telecommunity.com/protocol_ref/replintrowadapt.html for > some further thoughts on this. Basically, the problem is that if > you use interface detection in order to decide what to do with > something, you're basically taking away the ability for the > developer who comes *after* you to control what happens with the > objects they give you. Adaptation and generic functions don't have > this problem.) I haven't read those articles yet, but I still think I agree with this. :) - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRfana3EjvBPtnXfVAQJ7QgP8DSSdGQOi4H9F9DIAC+pOMBDr0641HgXp X1v8uZKXN+A6iOdht4SaghX7W5AUL2g8nP5CvoxF7zHMgsQB9pLUor8zMTwWplKe cxzi+hows9qalWkwZfdyXt+rYZS6reknPJPdgSDqJN4lmba/f7zuFyYiEVSKNgbw NH041Y5QGSc= =ejqN -----END PGP SIGNATURE----- _______________________________________________ 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
