[Python-Dev] Single- vs. Multi-pass iterability
Thu, 18 Jul 2002 07:52:34 +0200
On Thursday 18 July 2002 01:25 am, Greg Ewing wrote:
> Andrew Koenig <firstname.lastname@example.org>:
> > 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!