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

[Clark C . Evans]

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

Yes.

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

Exactly.


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

I agree here; having two methods doubles the complication 
without giving much additional value.   adapt() is more than
adequate, although I use check() to help explain the innerds.
If someone really insists on having check() exposed, the I 
don't see the harm... only that it makes the proposal seem more
complicated than it is.

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

Yes.  This would be an improvement of the proposal.  How do we
express this so that the protocol of core Types can do this
sort of enforcement.  Perhaps by giving the Protocol the ability
to "veto" the final result?

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

*nods*  

Clark
Yo!  Check out YAML.  http://yaml.org
YAML is language independent readable object serialization.

-- 
Clark C. Evans                   Axista, Inc.
http://www.axista.com            800.926.5525
XCOLLA Collaborative Project Management Software