Re: [Python-Dev] Single- vs. Multi-pass iterability
argue that making the file object its own iterator is only confusing; given that I'm also not sure what problem it solves, I'm at best +0 on
Personally, I think it solves at least a teaching problem -- it helps me teach the difference between iterators and iterables. In the Europython tutorial I had to gloss a bit over the fact that the difference was rather blurried. According to the principles I mentioned, as easiest for the audience to understand and apply, the file object SHOULD have been an iterator, not an iterable -- i.e. it SHOULD have been the case that f is iter(f) when f is a file object -- but it wasn't. When it IS, that's one less micro-wart I need to mention when teaching or writing about it.
I dunno. The presence of seek() and write() makes the behavior of files a rather unique blend of iterator and iterable.
I don't see any downside to having this micro-wart removed. In particular, I don't see what's confusing. Things that respond to iter(x) fall in two categories: iterators: also have x.next(), and iter(x) is x iterables: iter(x) is not x, so you can presumably get another iterator out of x at some later point in time if needed. It's not QUITE as simple as this, but moving file objects from the second category to the first seems to _simplify_ things a bit.
I worry that equating a file with its iterable makes it more likely that people mix next() with readline() or seek(), which doesn't work (at least not until the I/O system is rewritten). I'd be more comfortable with teaching people that you should *either* use a file in a for loop (the common case, probably) *or* use its native I/O methods (readline() etc.), but not mix both.
E.g.:
def useIterable(x): try: it = iter(x) except TypeError: raise TypeError, "Need iterable object, not %s" % type(x) if it is x: raise TypeError, "Need iterable object, not iterator" # keep happily using it and/or x as needed, and in particular # the code is able to call it1 = iter(x) if it needs to iterate again
Not perfect -- but having a file-object argument fail this simplistic test seems better to me, less confusing, than having it pass.
This actually looks like an example of the "look before you leap" (LBYL) syndrome, which you disapproved of recently.
So, I, personally, am +1. It might be even nicer (from the point of view of teaching, at least) if iterating on f interoperated more smoothly with other method calls on f, but I do see your point that the right way to achieve THAT would be a complete rewrite of the I/O system, and thus a vastly heavier project than the current one. Still, the current step seems to be in the right direction.
Somehow I'd rather emphasize the relative brokenness of the current situation. Anyway, I'm somewhere between -0 and +0 (inclusive) on this. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (3)
-
Alex Martelli
-
Greg Ewing
-
Guido van Rossum