[Python-Dev] lifting of prohibition against readlines inside a "for line in file" in Py3?
Nick Coghlan
ncoghlan at gmail.com
Wed Feb 18 22:19:58 CET 2009
Mitchell L Model wrote:
> I didn't get any response. Is this the wrong list for the question? Did
> appropriate responders assume another would respond?
Probably the latter (I know I left it to those that had more to do with
the IO stack rewrite). This is definitely the right list for the question.
> I want to reraise
> this because lifting of that prohibition is a quite significant change
> in the behavior from Python 2. Even if it ws a bug in Python 2, or the
> side effect of other changes in Python 3, it should at least be
> documented prominently. True, no-one's code will be affected by lifting
> a prohibition against something their code couldn't have done, but the
> new behavior offers significant flexibility in writing "for line in fil"
> iterations in that it allows recognizing the beginning of a sequence of
> lines that should be considered a unified "chunk" and allows the loop to
> do readlines to handle the rest of the chunk. Some of these can be
> handled by just nesting a second "for line in fil" inside a conditional
> inside the outer iteration but some are better handled by individual
> readlines.
>
> I'd appreciate comments -- especially a redirection to a different list,
> if this one isn't appropriate for my query.
I *think* the 2.x system had an internal buffer that was used by the
file iterator, but not by the file methods. With the new IO stack for
3.0, there is now a common buffer shared by all the file operations
(including iteration).
However, given that the lifting of the restriction is currently
undocumented, I wouldn't want to see a commitment to keeping it lifted
until we know that it won't cause any problems for the io-in-c rewrite
for 3.1 (hopefully someone with more direct involvement with that
rewrite will chime in, since they'll know a lot more about it than I do).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
More information about the Python-Dev
mailing list