[ python-Bugs-1714381 ] Universal line ending mode duplicates all line endings
Bugs item #1714381, was opened at 2007-05-07 14:50
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714381&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings
Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line
endings produces twice as many lines!
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'
I would expect the last to give "Hello\n".
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 11:06
Message:
Logged In: YES
user_id=849994
Originator: NO
To the OP: what does "open("winlineend", "rb").read()" return?
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-08 01:48
Message:
Logged In: YES
user_id=479790
Originator: NO
Yes, it's not so obvious, and the same question was posted a few days ago
on comp.lang.python.
I'll review the documentation and make it more clearly stated.
--
Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 21:36
Message:
Logged In: YES
user_id=769182
Originator: YES
I see. This seems like something of a gotcha to me: is it documented
anywhere? Seems to make os.linesep not very useful in fact, especially if
"\n" will work fine everywhere and is shorter.
It isn't at all obvious that file.write(os.linesep) will in fact write two
lines...
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 21:15
Message:
Logged In: YES
user_id=479790
Originator: NO
> file.write("Hello" + os.linesep)
The line separator for a file opened in *text*mode* is *always* \n in
Python code. It gets converted to os.linesep when you write the file; and
conversely, os.linesep get translated into a single \n when you read the
file.
On Windows, os.linesep is "\r\n". The argument to file.write above is
"Hello\r\n". That "\n" gets translated into "\r\n" when it is written, so
the actual file contents will be "Hello\r\n\n"
In short: if you open a file in text mode (the default) *don't* use
os.linesep to terminate lines. Only use os.linesep when writing text files
open in binary mode (and that's not a common case).
--
Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 20:27
Message:
Logged In: YES
user_id=769182
Originator: YES
I create the file as follows:
>>> import os
>>> file = open("test.txt", "w")
>>> file.write("Hello" + os.linesep)
>>> file.close()
>>> open("test.txt").read()
'Hello\r\n'
>>> open("test.txt", "rU").read()
'Hello\n\n'
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 17:39
Message:
Logged In: YES
user_id=984087
Originator: NO
I created a file "test.txt" with notepad whose contents are "hello\r\n".
Both open().read() and open("rU").read() returned 'hello\n'. I tested with
both 2.5 and 2.5.1 (installed using installers from python.org) and the
result is same on both. Can you elaborate your test case more? How is this
file "winlineend" created?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714381&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1697916 ] Segfaults on memory error
Bugs item #1697916, was opened at 2007-04-10 19:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 6 Private: No Submitted By: STINNER Victor (haypo) Assigned to: Georg Brandl (gbrandl) Summary: Segfaults on memory error Initial Comment: Hi, I'm playing with resource.setrlimit(resource.RLIMIT_AS) to limit memory usage during fuzzing tests. It works quite well but Python crashs sometimes (with SEGFAULT). I downloaded Python source code and recompiled it with EXTRA_FLAGS="-g -O0" to find errors. I found three bugs and wrote a patch for all of them. Comments: * Objects/exceptions.c:33: allocation may returns NULL on memory error * Objects/longobject.c:2511: long_divrem() may allocate new long integers but l_divmod() doesn't check that div and mod are not NULL * Objects/object.c:1284: problem with NULL mro. I don't understand how mro works, but I think that the error may be catched when mro is assigned. Problem: where is it done? in Objects/typeobject.c? So don't apply my patch directly: fix for object.c may be wrong. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-05-11 11:08 Message: Logged In: YES user_id=849994 Originator: NO Backported in rev 54902. -- Comment By: Georg Brandl (gbrandl) Date: 2007-04-11 20:11 Message: Logged In: YES user_id=849994 Originator: NO Reopening until I can backport this to the 2.5 branch. -- Comment By: STINNER Victor (haypo) Date: 2007-04-11 16:53 Message: Logged In: YES user_id=365388 Originator: YES Ignore my bug about NULL mro since i'm not able to reproduce it. Thanks for the 3 other fixes ;-) -- Comment By: Georg Brandl (gbrandl) Date: 2007-04-11 16:11 Message: Logged In: YES user_id=849994 Originator: NO Status update: Fixed the first two bugs locally, and a third one discovered by Victor on #python-dev. The mro one is unclear -- we've asked him to reproduce it and poke around in gdb to see why tp_mro is NULL, which it shouldn't be. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697916&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1697782 ] types.InstanceType is missing but used by pydoc
Bugs item #1697782, was opened at 2007-04-10 15:55 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697782&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 3000 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Georg Brandl (gbrandl) Summary: types.InstanceType is missing but used by pydoc Initial Comment: >>> help(callable.__call__) Traceback (most recent call last): File "", line 1, in File "/home/heimes/dev/python/p3yk/Lib/site.py", line 348, in __call__ return pydoc.help(*args, **kwds) File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1658, in __call__ self.help(request) File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1702, in help else: doc(request, 'Help on %s:') File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1477, in doc desc = describe(object) File "/home/heimes/dev/python/p3yk/Lib/pydoc.py", line 1436, in describe if type(thing) is types.InstanceType: AttributeError: 'module' object has no attribute 'InstanceType' -- >Comment By: Georg Brandl (gbrandl) Date: 2007-05-11 11:09 Message: Logged In: YES user_id=849994 Originator: NO Backported in rev 54905. -- Comment By: Georg Brandl (gbrandl) Date: 2007-04-11 20:11 Message: Logged In: YES user_id=849994 Originator: NO Reopening until I can backport this to the 2.5 branch. -- Comment By: Georg Brandl (gbrandl) Date: 2007-04-11 19:25 Message: Logged In: YES user_id=849994 Originator: NO Fixed all instances of types.InstanceType in rev. 54761. -- Comment By: Christian Heimes (tiran) Date: 2007-04-11 13:52 Message: Logged In: YES user_id=560817 Originator: YES types.InstanceType is still used by several stdlib modules. FIX: svn cp the types.py module from Python 2.6 to the p3yk branh -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697782&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1707255 ] lost global variables in main memory intensive execution
Bugs item #1707255, was opened at 2007-04-25 09:45 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707255&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Jordi Pujol Ahulló (jpahullo) Assigned to: Nobody/Anonymous (nobody) Summary: lost global variables in main memory intensive execution Initial Comment: Hello, I was running a very main memory intensive program in my computer. I looked for similar bugs or troubles in the site and I didn't found any similar to this. I know that the use of global variables is not recommended by software engineering, but for special cases it is very fast to develop/test some ideas. My problem statement is the following (very simplified and also attached): ## BEGINNING OF CODE #test for globals counter_1 = 0 def modifierfunction(): global counter_1 #some code counter_1 += 1 #some other code def test(): for i in range(2): global counter_1 counter_1 = 0 for j in range(10): modifierfunction() print "COUNTER_1:", counter_1 def test2(): global counter_1 for i in range(2): counter_1 = 0 for j in range(10): modifierfunction() print "COUNTER_1:", counter_1 if __name__ == "__main__": test() test2() ## END OF CODE Globally speaking, it is a global variable, defined at the begining of the python file (counter_1), and it is modified in some functions within it (in this example, modifierfunction). At the end, it appear some tests that make what I need. If you try to run this code, it will always show the expected values in the standard out. But, let me to show you my problem. In the beginning, I have the global statement as in test2. But I found that it only take a corrent value for the first iteration. The others it has always a zero value. I didn't understand anything. Then, some collegue suggested me to change the place of the global statement (as in test()), and then it worked correctly, as it was expected. I repeat. The above example works fine. But when this same structure, but with my big problem, very main memory intensive, test2() didn't work correctly. Thank you for your attention. Regards, Jordi -- >Comment By: Georg Brandl (gbrandl) Date: 2007-05-11 11:17 Message: Logged In: YES user_id=849994 Originator: NO The resulting bytecode the functions are compiled to is exactly the same, no matter where the global statement is. So I cannot believe that moving the global statement alone causes something that failed to work. -- Comment By: Calvin Spealman (ironfroggy) Date: 2007-04-28 14:59 Message: Logged In: YES user_id=112166 Originator: NO If you really think there is a bug, don't post working code, post code that actually demonstrates the problem. Something anyone else could use to reproduce the bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707255&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1714381 ] Universal line ending mode duplicates all line endings
Bugs item #1714381, was opened at 2007-05-07 16:50
Message generated for change (Comment added) made by gjb1002
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714381&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings
Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line
endings produces twice as many lines!
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'
I would expect the last to give "Hello\n".
--
>Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-11 20:34
Message:
Logged In: YES
user_id=769182
Originator: YES
It returns "Hello\r\r\n" (not "Hello\r\n\n" as was suggested earlier)
Don't know quite how it does this from simply writing os.linesep.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 13:06
Message:
Logged In: YES
user_id=849994
Originator: NO
To the OP: what does "open("winlineend", "rb").read()" return?
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-08 03:48
Message:
Logged In: YES
user_id=479790
Originator: NO
Yes, it's not so obvious, and the same question was posted a few days ago
on comp.lang.python.
I'll review the documentation and make it more clearly stated.
--
Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 23:36
Message:
Logged In: YES
user_id=769182
Originator: YES
I see. This seems like something of a gotcha to me: is it documented
anywhere? Seems to make os.linesep not very useful in fact, especially if
"\n" will work fine everywhere and is shorter.
It isn't at all obvious that file.write(os.linesep) will in fact write two
lines...
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 23:15
Message:
Logged In: YES
user_id=479790
Originator: NO
> file.write("Hello" + os.linesep)
The line separator for a file opened in *text*mode* is *always* \n in
Python code. It gets converted to os.linesep when you write the file; and
conversely, os.linesep get translated into a single \n when you read the
file.
On Windows, os.linesep is "\r\n". The argument to file.write above is
"Hello\r\n". That "\n" gets translated into "\r\n" when it is written, so
the actual file contents will be "Hello\r\n\n"
In short: if you open a file in text mode (the default) *don't* use
os.linesep to terminate lines. Only use os.linesep when writing text files
open in binary mode (and that's not a common case).
--
Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 22:27
Message:
Logged In: YES
user_id=769182
Originator: YES
I create the file as follows:
>>> import os
>>> file = open("test.txt", "w")
>>> file.write("Hello" + os.linesep)
>>> file.close()
>>> open("test.txt").read()
'Hello\r\n'
>>> open("test.txt", "rU").read()
'Hello\n\n'
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 19:39
Message:
Logged In: YES
user_id=984087
Originator: NO
I created a file "test.txt" with notepad whose contents are "hello\r\n".
Both open().read() and open("rU").read() returned 'hello\n'. I tested with
both 2.5 and 2.5.1 (installed using installers from python.org) and the
result is same on both. Can you elaborate your test case more? How is this
file "winlineend" created?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714381&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1714381 ] Universal line ending mode duplicates all line endings
Bugs item #1714381, was opened at 2007-05-07 14:50
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714381&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings
Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line
endings produces twice as many lines!
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'
I would expect the last to give "Hello\n".
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 18:41
Message:
Logged In: YES
user_id=849994
Originator: NO
Okay, that settles it.
When you write "\r\n" to a Windows text file, it writes "\r\r\n"
(since "\n" is converted to "\r\n"). When universal newline mode
sees that, it thinks of it as Mac-lineend followed by a Windows-
lineend.
The doc fix has been committed, closing this one as "won't fix".
--
Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-11 18:34
Message:
Logged In: YES
user_id=769182
Originator: YES
It returns "Hello\r\r\n" (not "Hello\r\n\n" as was suggested earlier)
Don't know quite how it does this from simply writing os.linesep.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 11:06
Message:
Logged In: YES
user_id=849994
Originator: NO
To the OP: what does "open("winlineend", "rb").read()" return?
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-08 01:48
Message:
Logged In: YES
user_id=479790
Originator: NO
Yes, it's not so obvious, and the same question was posted a few days ago
on comp.lang.python.
I'll review the documentation and make it more clearly stated.
--
Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 21:36
Message:
Logged In: YES
user_id=769182
Originator: YES
I see. This seems like something of a gotcha to me: is it documented
anywhere? Seems to make os.linesep not very useful in fact, especially if
"\n" will work fine everywhere and is shorter.
It isn't at all obvious that file.write(os.linesep) will in fact write two
lines...
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 21:15
Message:
Logged In: YES
user_id=479790
Originator: NO
> file.write("Hello" + os.linesep)
The line separator for a file opened in *text*mode* is *always* \n in
Python code. It gets converted to os.linesep when you write the file; and
conversely, os.linesep get translated into a single \n when you read the
file.
On Windows, os.linesep is "\r\n". The argument to file.write above is
"Hello\r\n". That "\n" gets translated into "\r\n" when it is written, so
the actual file contents will be "Hello\r\n\n"
In short: if you open a file in text mode (the default) *don't* use
os.linesep to terminate lines. Only use os.linesep when writing text files
open in binary mode (and that's not a common case).
--
Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 20:27
Message:
Logged In: YES
user_id=769182
Originator: YES
I create the file as follows:
>>> import os
>>> file = open("test.txt", "w")
>>> file.write("Hello" + os.linesep)
>>> file.close()
>>> open("test.txt").read()
'Hello\r\n'
>>> open("test.txt", "rU").read()
'Hello\n\n'
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 17:39
Message:
Logged In: YES
user_id=984087
Originator: NO
I created a file "test.txt" with notepad whose contents are "hello\r\n".
Both open().read() and open("rU").read() returned 'hello\n'. I tested with
both 2.5 and 2.5.1 (installed using installers from python.org) and the
result is same on both. Can you elaborate your test case more? How is this
file "winlineend" created?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714381&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://m
[ python-Bugs-1714381 ] Universal line ending mode duplicates all line endings
Bugs item #1714381, was opened at 2007-05-07 16:50
Message generated for change (Comment added) made by gjb1002
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714381&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Closed
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings
Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line
endings produces twice as many lines!
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'
I would expect the last to give "Hello\n".
--
>Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-11 20:50
Message:
Logged In: YES
user_id=769182
Originator: YES
Which doc has been changed? Can I review it somewhere?
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 20:41
Message:
Logged In: YES
user_id=849994
Originator: NO
Okay, that settles it.
When you write "\r\n" to a Windows text file, it writes "\r\r\n"
(since "\n" is converted to "\r\n"). When universal newline mode
sees that, it thinks of it as Mac-lineend followed by a Windows-
lineend.
The doc fix has been committed, closing this one as "won't fix".
--
Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-11 20:34
Message:
Logged In: YES
user_id=769182
Originator: YES
It returns "Hello\r\r\n" (not "Hello\r\n\n" as was suggested earlier)
Don't know quite how it does this from simply writing os.linesep.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 13:06
Message:
Logged In: YES
user_id=849994
Originator: NO
To the OP: what does "open("winlineend", "rb").read()" return?
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-08 03:48
Message:
Logged In: YES
user_id=479790
Originator: NO
Yes, it's not so obvious, and the same question was posted a few days ago
on comp.lang.python.
I'll review the documentation and make it more clearly stated.
--
Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 23:36
Message:
Logged In: YES
user_id=769182
Originator: YES
I see. This seems like something of a gotcha to me: is it documented
anywhere? Seems to make os.linesep not very useful in fact, especially if
"\n" will work fine everywhere and is shorter.
It isn't at all obvious that file.write(os.linesep) will in fact write two
lines...
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 23:15
Message:
Logged In: YES
user_id=479790
Originator: NO
> file.write("Hello" + os.linesep)
The line separator for a file opened in *text*mode* is *always* \n in
Python code. It gets converted to os.linesep when you write the file; and
conversely, os.linesep get translated into a single \n when you read the
file.
On Windows, os.linesep is "\r\n". The argument to file.write above is
"Hello\r\n". That "\n" gets translated into "\r\n" when it is written, so
the actual file contents will be "Hello\r\n\n"
In short: if you open a file in text mode (the default) *don't* use
os.linesep to terminate lines. Only use os.linesep when writing text files
open in binary mode (and that's not a common case).
--
Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 22:27
Message:
Logged In: YES
user_id=769182
Originator: YES
I create the file as follows:
>>> import os
>>> file = open("test.txt", "w")
>>> file.write("Hello" + os.linesep)
>>> file.close()
>>> open("test.txt").read()
'Hello\r\n'
>>> open("test.txt", "rU").read()
'Hello\n\n'
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 19:39
Message:
Logged In: YES
user_id=984087
Originator: NO
I created a file "test.txt" with notepad whose contents are "hello\r\n".
Both open().read() and open("rU").read() returned 'hello\n'. I tested with
both 2.5 and 2.5.1 (installed using installers from python.org) and the
result is same on both. Can you elaborate your test case more? How is this
file "winlineend" created?
-
[ python-Bugs-1714381 ] Universal line ending mode duplicates all line endings
Bugs item #1714381, was opened at 2007-05-07 14:50
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714381&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Closed
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal line ending mode duplicates all line endings
Initial Comment:
On Windows XP, reading a file produced by Windows XP with universal line
endings produces twice as many lines!
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "copyright", "credits" or "license()" for more information.
>>> open("winlineend").read()
'Hello\r\n'
>>> open("winlineend", "rU").read()
'Hello\n\n'
I would expect the last to give "Hello\n".
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 19:38
Message:
Logged In: YES
user_id=849994
Originator: NO
The doc for os.linesep. The change is in Subversion, and will be at
docs.python.org/dev when the build script runs the next time.
--
Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-11 18:50
Message:
Logged In: YES
user_id=769182
Originator: YES
Which doc has been changed? Can I review it somewhere?
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 18:41
Message:
Logged In: YES
user_id=849994
Originator: NO
Okay, that settles it.
When you write "\r\n" to a Windows text file, it writes "\r\r\n"
(since "\n" is converted to "\r\n"). When universal newline mode
sees that, it thinks of it as Mac-lineend followed by a Windows-
lineend.
The doc fix has been committed, closing this one as "won't fix".
--
Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-11 18:34
Message:
Logged In: YES
user_id=769182
Originator: YES
It returns "Hello\r\r\n" (not "Hello\r\n\n" as was suggested earlier)
Don't know quite how it does this from simply writing os.linesep.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 11:06
Message:
Logged In: YES
user_id=849994
Originator: NO
To the OP: what does "open("winlineend", "rb").read()" return?
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-08 01:48
Message:
Logged In: YES
user_id=479790
Originator: NO
Yes, it's not so obvious, and the same question was posted a few days ago
on comp.lang.python.
I'll review the documentation and make it more clearly stated.
--
Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 21:36
Message:
Logged In: YES
user_id=769182
Originator: YES
I see. This seems like something of a gotcha to me: is it documented
anywhere? Seems to make os.linesep not very useful in fact, especially if
"\n" will work fine everywhere and is shorter.
It isn't at all obvious that file.write(os.linesep) will in fact write two
lines...
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 21:15
Message:
Logged In: YES
user_id=479790
Originator: NO
> file.write("Hello" + os.linesep)
The line separator for a file opened in *text*mode* is *always* \n in
Python code. It gets converted to os.linesep when you write the file; and
conversely, os.linesep get translated into a single \n when you read the
file.
On Windows, os.linesep is "\r\n". The argument to file.write above is
"Hello\r\n". That "\n" gets translated into "\r\n" when it is written, so
the actual file contents will be "Hello\r\n\n"
In short: if you open a file in text mode (the default) *don't* use
os.linesep to terminate lines. Only use os.linesep when writing text files
open in binary mode (and that's not a common case).
--
Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-07 20:27
Message:
Logged In: YES
user_id=769182
Originator: YES
I create the file as follows:
>>> import os
>>> file = open("test.txt", "w")
>>> file.write("Hello" + os.linesep)
>>> file.close()
>>> open("test.txt").read()
'Hello\r\n'
>>> open("test.txt", "rU").read()
'Hello\n\n'
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 17:39
Message:
Logged In: YES
user_id=984087
Originator: NO
I created a file "test.txt" with notepad whose
