opinion - file.readlines blemish

[Ken Seehart]

I was just reading about the new file.newlines method that was added per 
PEP 278.  I suspect Guido must have been looking in some other direction 
when this got added, because it seems unlikely to me that he would have 
let this get by...  Okay, maybe I'm being a little harsh :-)   Sorry, 
I'm picky about this kind of thing.  The again, maybe I'm just missing 
some key point.


      file.newlines

    *newlines*

    If Python was built with the *---with-universal-newlines* option to
    *configure* (the default) this read-only attribute exists, and for
    files opened in universal newline read mode it keeps track of the
    types of newlines encountered while reading the file. The values it
    can take are |'\r'|, |'\n'|, |'\r\n'|, *None*
    <http://effbot.org/pyref/None.htm> (unknown, no newlines read yet)
    or a tuple containing all the newline types seen, to indicate that
    multiple newline conventions were encountered. For files not opened
    in universal newline read mode the value of this attribute will be
    *None* <http://effbot.org/pyref/None.htm>.


It seems immediately obvious to me that the return value should always 
be a tuple, consisting of zero or more strings.  If built with universal 
newlines, it should return ('\n',) if a newline was found.

Perhaps there was some blurry contemplation that the None return value 
could identify that *universal-newlines* is enabled, but this is blurry 
because None could also just mean that no newlines have been read.  
Besides, it's not a good idea to stuff extra semantics like that.  
Better would be a separate way to identify *universal-newlines *mode.

Ken Seehart


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20071103/2e5bfcb2/attachment.html>