On Thursday 18 July 2002 01:25 am, Greg Ewing wrote:
Andrew Koenig <ark@research.att.com>:
Is a file a container or not?
I would say no, a file object is not a container in Python terms. You can't index it with [] or use len() on it or any of the other things you expect to be able to do on containers.
I think we just have to live with the idea that there are things other than containers that can supply iterators.
Yes, there are such things, and there may be cases in which no other alternative makes sense. But I don't think files are necessarily in such a bind.
Forcing everything that can supply an iterator to bend over backwards to try to be a random-access container as well would be too cumbersome.
Absolutely. But what Oren's patch does, and my mods of it preserve, is definitely NOT "forcing" files "to be random- access containers": on the contrary, it accepts the fact that files aren't containers and conceptually simplifies things by making them iterators instead. I'm not sure about "random access" being needed to be a container. Consider sets, e.g. as per Greg Wilson's soapbox implementation (as modified by my patch to allow immutable-sets, maybe, but that's secondary). They're doubtlessly containers, able to produce on request as many iterators as you wish, each iterator not affecting the set's state in any way -- the ideal. But what sense would it make to force sets to expose a __getitem__? Right now they inherit from dict and thus do happen to expose it, but that's really an implementation artefact showing through (and a good example of why one might like to inherit without needing to expose all of the superclass's interface, to tie this in to another recent thread -- inheritance for implementation). Ideally, sets would expose __contains__, __iter__, __len__, ways to add and remove elements, and perhaps (it's so in Greg's implementation, and I didn't touch that) set ops such as union, intersection &c. someset[anindex] is really a weird thing to have... yet sets _are_ containers! Alex