[Python-3000] Discussions with no PEPs

[Barry Warsaw]

-----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-----