[Python-Dev] PEP 246, redux

[Phillip J. Eby]

At 07:52 PM 1/11/05 -0500, Raymond Hettinger wrote:
>Also, it is not clear to me how or if existing manual adaption practices
>should change.  For example, if I need a file-like interface to a
>string, I currently wrap it with StringIO.  How will that change it the
>future?  By an explicit adapt/conform pair?  Or by strings knowing how
>to conform to file-like requests?

The goal here is to be able to specify that a function parameter takes, 
e.g. a "readable stream", and that you should be able to either explicitly 
wrap in a StringIO to satisfy this, or *possibly* that you be able to just 
pass a string and have it work automatically.

If the latter is the case, there are a variety of possible ways it might 
work.  str.__conform__ might recognize the "readable stream" interface, or 
the __adapt__ method of the "readable stream" interface could recognize 
'str'.  Or, Alex's new proposed global type registry might contain an entry 
for 'str,readableStream'.  Which of these is the preferred scenario very 
much depends on a lot of things, like who defined the "readable stream" 
interface, and whether anybody has registered an adapter for it!

PyProtocols tries to answer this question by allowing you to register 
adapters with interfaces, and then the interface's __adapt__ method will do 
the actual adaptation.  Zope does something similar, at least in that it 
uses the interface's __adapt__ method, but that method actually uses a 
global registry.

Neither PyProtocols nor Zope make much use of actually implementing 
hand-coded __conform__ or __adapt__ methods, as it's too much trouble for 
something that's so inherently declarative anyway, and only the creator of 
the object class or the interface's type have any ability to define 
adapters that way.  Given that built-in types are often handy sources of 
adaptation (e.g. str-to-StringIO in your example), it isn't practical in 
present-day Python to add a __conform__ method to the str type!

Thus, in the general case it just seems easier to use a per-interface or 
global registry for most normal adaptation, rather than using 
__conform__.  However, having __conform__ exist is a nice "out" for 
implementing unusual custom requirements (like easy dynamic conformance), 
so I don't think it should be removed.