> > 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/)
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