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
--
http://mail.python.org/mailman/listinfo/python-list
