[Python-Dev] Re: PEP 246, Object Adaptation (was Re: Single- vs. Multi-pass iterability)

[Alex Martelli]

On Monday 15 July 2002 05:58 pm, Clark C . Evans wrote:
> On Mon, Jul 15, 2002 at 10:22:25AM -0400, Aahz wrote:
> | in fact, it suffers from the obverse problem.  Consider this:
> |
> |     class C:
> |         def open(self, name, flags=None):
> |         def read(self):
> |         def write(self, value):
> |         def close(self):
> |
> | Can instances of C be used where a file object is expected?
>
> From the "Object Adaptation" perspective, you would have a file
> protocol (perhaps the built-in File object works).    And then

If so, then presumably the answer is "no", since the built-in
file object has many more important methods such as seek and
tell.  If the file type itself serves as the protocol, surely that should
mean "implement all of the methods" rather than just some of
them.

Moreover, a file's read method accepts an optional integer.  Class C's
read method does not.  So, even the methods that C does supply
are not compliant with those of a file object.

Some, but not all, current uses of "file-like objects" may be satisfied
with just a .read method that must be called without arguments --
other would need the argument to be accepted, others yet would
need readline instead, not to speak of seeking behavior (which all
file object expose, but not all _implement_...).

To use adaptation, we may need to be more precise than just saying
"a file object is expected" -- IF only a SUBSET of the file object's
methods (or a subset of their signatures) is indeed expected.


> you could call "check()" or "adapt()" built-in functions.
>
>   check() at a high level, this built-in function first asks
>           the object iself directly: "Hey are you a File?"
>           if the response is affirmative or negative, then the
>           search is done.   If the object doesn't respond (either
>           it lacks __check or __check returns None) then the
>           built-in then goes and asks the protocol object if the
>           file complies.   When all else fails, the built-in
>           could use some default logic of its own.
>
>   adapt() returns the object itself if check() is true; otherwise
>           it asks the object and then the protocol to provide
>           a wrapper.  If neither provide the wrapper, then an
>           error is thrown.

I don't see the need or opportunity to have a check() that
is separate from adapt().  COM's QueryInterface only has the
equivalent of adapt(), and that's quite enough.  PEP 246 does
not specify a check() built-in, either.  


> The key thing about the Object Adaptation proposal is that it
> leaves wide open what it means to comply.  This flexibility is

Yes, but I see it as a minimum that a "compliant" object has
a set of methods callable with given signatures.  If a protocol is
represented by a type, the set should comprise the type's methods.

While it WOULD be nice to extend this further, we can see just
from examining file objects that this is probably impractical -- they
all do have (e.g.) methods write and seek, but if you call those
methods on a given file object f, f may raise exceptions because
it's not really writable or seekable.  So "having a method" is not
a sufficient condition for REALLY having it, if you see what I mean.


Alex