Paul> I suggested this at one point but it was pointed out that there is
Paul> probably a lot of code that works with the resulting list *as a
Paul> list*
How about this idea? What if readlines() was allowed to return a lazy
evaluator if a sizehint > 0 was given? I only saw one example outside of
test cases in the current CVS tree where readlines(sizehint) was used
(Tools/idle/GrepDialog.py), and it used it as expected:
while 1:
block = f.readlines(sizehint)
if not block:
break
for line in block:
more stuff
My suspicion is that most uses of sizehint will be like this. It hasn't
been around all that long in Python-years (since 1.5a2), so there's probably
not tons of code to break (I agree the semantics would change), and the
majority of code that uses it probably looks like the above, which is almost
safe (if it returned "" instead of an empty evaluator when nothing was left
to read it would be safe). The advantage would be that the above could
become the more obvious
for line in f.readlines(sizehint):
more stuff
and the change to file reading code that is "too slow" becomes much simpler.
(Of course, xreadlines() has that advantage as well.)
I scanned my own code quickly. I found about 10 uses with sizehint and 300
without.
I presume we are talking about 2.1 here. In any case, it seems to me that
in Py3k readlines should be lazy.
Skip
P.S. Why did FileInput class never grow a readlines method?
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