[Python-Dev] PEP 246, redux

[Ian Bicking]

Phillip J. Eby wrote:
> Anyway, I'm honestly curious as to whether anybody can find a real 
> situation where transitive adapter composition is an *actual* problem, 
> as opposed to a theoretical one.  I've heard a lot of people talk about 
> what a bad idea it is, but I haven't heard any of them say they actually 
> tried it.  Conversely, I've also heard from people who *have* tried it, 
> and liked it.  However, at this point I have no way to know if this 
> dichotomy is just a reflection of the fact that people who don't like 
> the idea don't try it, and the people who either like the idea or don't 
> care are open to trying it.

I haven't read through the entire thread yet, so forgive me if I'm 
redundant.

One case occurred to me with the discussion of strings and files, i.e., 
adapting from a string to a file.  Let's say an IReadableFile, since 
files are too ambiguous.

Consider the case where we are using a path object, like Jason 
Orendorff's or py.path.  It seems quite reasonable and unambiguous that 
a string could be adapted to such a path object.  It also seems quite 
reasonable and unambiguous that a path object could be adapted to a 
IReadableFile by opening the file at the given path.  It's also quite 
unambiguous that a string could be adapted to a StringIO object, though 
I'm not sure it's reasonable.  In fact, it seems like an annoying but 
entirely possible case that some library would register such an adapter, 
and mess things up globally for everyone who didn't want such an 
adaptation to occur!  But that's an aside.  The problem is with the 
first example, where two seemingly innocuous adapters (string->path, 
path->IReadableFile) allow a new adaptation that could cause all sorts 
of problems (string->IReadableFile).

Ideally, if I had code that was looking for a file object and I wanted 
to accept filenames, I'd want to try to adapt to file, and if that 
failed I'd try to adapt to the path object and then from there to the 
file object.  Or if I wanted it to take strings (that represented 
content) or file-like objects, I'd adapt to a file object and if that 
failed I'd adapt to a string, then convert to a StringIO object.  A 
two-step adaptation encodes specific intention that it seems transitive 
adaption would be blind to.

As I think these things through, I'm realizing that registered 
adaptators really should be 100% accurate (i.e., no information loss, 
complete substitutability), because a registered adapter that seems 
pragmatically useful in one place could mess up unrelated code, since 
registered adapters have global effects.  Perhaps transitivity seems 
dangerous because that has the potential to dramatically increase the 
global effects of those registered adapters.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org