Martin Panter added the comment:

According to <https://bugs.python.org/issue20423#msg209581> Serhiy and Antoine 
both seem to agree this behaviour is a bug. The reason why newline="\r\n" and 
newline="\r" cause these funny translations is that __init__() internally 
passes the initial buffer value through write(). So I propose to set the buffer 
directly without using write().

However, doing this would have another effect. In the C implementation, write() 
also does universal newline decoding. The Python implementation had similar 
decoding added in getvalue() to compensate (Issue 20435). I propose to revert 
the getvalue() decoding, and to move the universal decoding from write() to 
read() in the C implementation.

I anticipate the combined effect of these changes would be:

1. StringIO("\n", newline="\r\n") no longer encodes the newline to CRLF in the 
internal buffer, so reading or getvalue() will return "\n" unencoded

2. StringIO("\r\n", newline=None).getvalue() returns "\r\n" undecoded, rather 
than universal decoding changing it to "\n"

3. s = StringIO(newline=None); s.write("\r\n"); s.getvalue() also returns 
"\r\n" undecoded. It is undocumented, but StringIO intentionally does not 
encode to os.linesep (yet another bug IMO).

4. StringIO.newlines would only get updated during reading, rather than during 
construction and writing, since newline decoding will only take place during 
reading.

There is another bug where the universal newline decoding does not anticipate 
split CRLF sequences. This would hopefully be fixed at the same time.

>>> s = io.StringIO(newline=None)
>>> s.write("\r\n" "\r")
3
>>> s.write("\n")  # Complete second CRLF
1
>>> s.getvalue()  # Should be "\r\n\r\n", at least when os.linesep == "\n"
'\n\n\n'

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22413>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to