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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4