opinion - file.readlines blemish

Gabriel Genellina gagsl-py2 at yahoo.com.ar
Mon Nov 5 02:33:23 EST 2007


En Sat, 03 Nov 2007 15:00:46 -0300, Ken Seehart <ken at seehart.com> escribi�:

>     *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.

I don't fully understand your concerns.
If Python was compiled with universal newlines support, the "newline"  
attribute exists; if not, it doesn't exist.
If it exists, and certain particular file was open with universal newline  
mode ("rU" by example), None means "no end of line read yet", any other  
values represent the end-of-line markers already seen. If the file was not  
opened in universal newline mode, that attribute will always be None. You  
usually know whether the file was opened in universal newline mode or not,  
but in any case, you can always look at the "mode" file attribute.

As why is not always a tuple, even with 0 or 1 element: I can guess that  
it's some kind of optimization. Most programs don't even care about this  
attribute, and most files will contain only one kind of end-of-line  
markers, so None and a single string would be the most common values. Why  
build a tuple (it's not free) when it's not needed most of the time?

-- 
Gabriel Genellina




More information about the Python-list mailing list