anatoly techtonik [EMAIL PROTECTED] added the comment:
This '\r' makes things worse. I am also on Windows and didn't thought
that rb processes '\r\n' linefeeds as a side-effect of '\n' being the
last character. Thanks.
newline='' is just what I need. I guess there is no alternative to it in
2.5
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Please read
http://docs.python.org/dev/library/io.html#io.TextIOBase.newlines
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3359
___
Skip Montanaro [EMAIL PROTECTED] added the comment:
As I indicated in msg69679 if you want to see the line endings just open
the file in binary mode ('rb').
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3359
anatoly techtonik [EMAIL PROTECTED] added the comment:
If lineends are mixed I would like to leave them as is.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3359
___
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Did you look at the io.open() function?
It's a new module in python2.6, but also the builtin open in py3k!
* On input, if newline is None, universal newlines mode is
enabled. Lines in the input can end in '\n', '\r', or
anatoly techtonik [EMAIL PROTECTED] added the comment:
That's fine with me. I just need a 'rbU' mode to know in which format
should I write the output file if I want to preserve proper line endings
regardless of platform.
As for Python 2.6 note - I would replace may convert with converts.
Georg Brandl [EMAIL PROTECTED] added the comment:
If you want to write your own line endings, read with rU and write
with rb.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3359
___
Georg Brandl [EMAIL PROTECTED] added the comment:
At least the 2.6 docs say
The default is to use text mode, which may convert ``'\n'`` characters
to a platform-specific representation on writing and back on reading.
___
Python tracker [EMAIL PROTECTED]
anatoly techtonik [EMAIL PROTECTED] added the comment:
This behavior is inherited from the C-level fopen() and therefore
normal text mode is whatever that defines.
Is this really nowhere documented?
Relation to fopen() function may be documented, but there is no
explanation of what normal
Georg Brandl [EMAIL PROTECTED] added the comment:
This behavior is inherited from the C-level fopen() and therefore
normal text mode is whatever that defines.
Is this really nowhere documented?
___
Python tracker [EMAIL PROTECTED]
Skip Montanaro [EMAIL PROTECTED] added the comment:
anatoly If you open file with 'r' - all line endings will be mapped
anatoly precisely to '\n' anyways, so it has nothing to do with 'U'
anatoly mode.
Before 3.0 at least, if you copy a text file from, say, Windows to Mac, and
open it
Skip Montanaro [EMAIL PROTECTED] added the comment:
The whole idea of universal newline mode is that the various possible
line endings ('\r', '\n' and '\r\n') are all mapped to '\n' precisely
so the user doesn't have to detect and fiddle with them. Using 'b' and
'U' together makes no sense.
*
anatoly techtonik [EMAIL PROTECTED] added the comment:
If you open file with 'r' - all line endings will be mapped precisely to
'\n' anyways, so it has nothing to do with 'U' mode.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3359
Georg Brandl [EMAIL PROTECTED] added the comment:
If you open file with 'r' - all line endings will be mapped precisely to
'\n' anyways, so it has nothing to do with 'U' mode.
No they won't -- only the platform-specific newline will. On Unix, 'r'
and 'rb' are the same.
--
nosy:
New submission from anatoly techtonik [EMAIL PROTECTED]:
'rU' universal newline support is useless, because read lines end with
'\n' regardless of actual line end in the source file. Applications that
care about line ends still open file in binary mode and gather the stats
manually.
So, to
15 matches
Mail list logo
