[ python-Bugs-1713999 ] Multiple re.compile flags cause error
Bugs item #1713999, was opened at 2007-05-07 02:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713999&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: Regular Expressions Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Saul Spatz (saulspatz) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Multiple re.compile flags cause error Initial Comment: The documentation for re.compile() shows that multiple flags are allowed, but re.compile(r'.*', re.VERBOSE, re.DOTALL) results in an error message that only two arguments are allowed and three were given. I'm using python 2.5 with Windows XP Home edition. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-05-07 08:35 Message: Logged In: YES user_id=849994 Originator: NO Closing as invalid. -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-07 05:10 Message: Logged In: YES user_id=479790 Originator: NO Multiple flags must be ORed together: re.compile(r'.*', re.VERBOSE | re.DOTALL) >From the re module documentation at http://docs.python.org/lib/node46.html: "Values can be any of the following variables, combined using bitwise OR (the | operator)." -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713999&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 (Tracker Item Submitted) made by Item Submitter
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".
--
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-Feature Requests-1714448 ] if something as x:
Feature Requests item #1714448, was opened at 2007-05-07 21:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1714448&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: k0wax (k0wax) Assigned to: Nobody/Anonymous (nobody) Summary: if something as x: Initial Comment: --- if map[x][y].overlay: map[x][y].overlay.blit(x,y) --- ... and ... --- if map[x][y].overpay as ob: ob.blit(x, y) --- the second one looks much more fun I think. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1714448&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1714448 ] if something as x:
Feature Requests item #1714448, was opened at 2007-05-07 21:09 Message generated for change (Settings changed) made by k0wax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1714448&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: None Status: Open Resolution: None >Priority: 1 Private: No Submitted By: k0wax (k0wax) Assigned to: Nobody/Anonymous (nobody) Summary: if something as x: Initial Comment: --- if map[x][y].overlay: map[x][y].overlay.blit(x,y) --- ... and ... --- if map[x][y].overpay as ob: ob.blit(x, y) --- the second one looks much more fun I think. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1714448&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1714451 ] subprocess.py problems errors when calling cmd.exe
Bugs item #1714451, was opened at 2007-05-07 17:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714451&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: tzellman (tzellman)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.py problems errors when calling cmd.exe
Initial Comment:
An example:
>>> import subprocess
>>> proc = subprocess.Popen('"c:\Windows\system\ping.exe" "localhost"',
>>> shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
'c:\Windows\system32\ping.exe" "localhost' is not recognized as an internal or
external command, operable program or batch file.
This normally works from the cmd.exe prompt, so the command line is being
passed incorrectly in the subprocess module.
My ACTUAL use case arises when I want to call the Microsoft compiler (CL.exe),
and add include directories that have spaces in the name. For example:
"C:\Program Files\Microsoft Visual Studio 8\VC\BIN\CL.exe" /TC /O2 /DNDEBUG /W3
/nologo /c /EHsc /errorReport:prompt /Idefault\ /I.. /I. /Idefault
/I"C:\Program Files\GnuWin32" /DWIN32 ..\pcreposix.c /Fodefault\pcreposix.obj
The fix for this problem is to modify line 765 in subprocess.py, replacing it
with:
args = comspec + " /s /c \"%s\"" % args.replace('""', '"')
The /s tells cmd.exe not to re-format the command line. We then encase the
entire command line in double quotes. I also replace occurrences of "" with "
in the arg string, in case the user already encased the command in double
quotes.
With this fix, the commands execute correctly.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714451&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1714451 ] subprocess.py problems errors when calling cmd.exe
Bugs item #1714451, was opened at 2007-05-07 17:13
Message generated for change (Comment added) made by tzellman
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714451&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: tzellman (tzellman)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.py problems errors when calling cmd.exe
Initial Comment:
An example:
>>> import subprocess
>>> proc = subprocess.Popen('"c:\Windows\system\ping.exe" "localhost"',
>>> shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
'c:\Windows\system32\ping.exe" "localhost' is not recognized as an internal or
external command, operable program or batch file.
This normally works from the cmd.exe prompt, so the command line is being
passed incorrectly in the subprocess module.
My ACTUAL use case arises when I want to call the Microsoft compiler (CL.exe),
and add include directories that have spaces in the name. For example:
"C:\Program Files\Microsoft Visual Studio 8\VC\BIN\CL.exe" /TC /O2 /DNDEBUG /W3
/nologo /c /EHsc /errorReport:prompt /Idefault\ /I.. /I. /Idefault
/I"C:\Program Files\GnuWin32" /DWIN32 ..\pcreposix.c /Fodefault\pcreposix.obj
The fix for this problem is to modify line 765 in subprocess.py, replacing it
with:
args = comspec + " /s /c \"%s\"" % args.replace('""', '"')
The /s tells cmd.exe not to re-format the command line. We then encase the
entire command line in double quotes. I also replace occurrences of "" with "
in the arg string, in case the user already encased the command in double
quotes.
With this fix, the commands execute correctly.
--
>Comment By: tzellman (tzellman)
Date: 2007-05-07 17:20
Message:
Logged In: YES
user_id=1090960
Originator: YES
This could likely be rejected.
I realize a solution to this w/o modifying the Python source is to encase
the expression yourself in double quotes. So, the example given would look
like:
>>> import subprocess
>>> proc = subprocess.Popen('""c:\Windows\system\ping.exe" "localhost""',
shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
And that will work.
Sorry for any confusion.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714451&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 10:50
Message generated for change (Comment added) made by draghuram
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: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 13: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 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-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-1714451 ] subprocess.py problems errors when calling cmd.exe
Bugs item #1714451, was opened at 2007-05-07 14:13
Message generated for change (Comment added) made by gagenellina
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714451&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: tzellman (tzellman)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.py problems errors when calling cmd.exe
Initial Comment:
An example:
>>> import subprocess
>>> proc = subprocess.Popen('"c:\Windows\system\ping.exe" "localhost"',
>>> shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
'c:\Windows\system32\ping.exe" "localhost' is not recognized as an internal or
external command, operable program or batch file.
This normally works from the cmd.exe prompt, so the command line is being
passed incorrectly in the subprocess module.
My ACTUAL use case arises when I want to call the Microsoft compiler (CL.exe),
and add include directories that have spaces in the name. For example:
"C:\Program Files\Microsoft Visual Studio 8\VC\BIN\CL.exe" /TC /O2 /DNDEBUG /W3
/nologo /c /EHsc /errorReport:prompt /Idefault\ /I.. /I. /Idefault
/I"C:\Program Files\GnuWin32" /DWIN32 ..\pcreposix.c /Fodefault\pcreposix.obj
The fix for this problem is to modify line 765 in subprocess.py, replacing it
with:
args = comspec + " /s /c \"%s\"" % args.replace('""', '"')
The /s tells cmd.exe not to re-format the command line. We then encase the
entire command line in double quotes. I also replace occurrences of "" with "
in the arg string, in case the user already encased the command in double
quotes.
With this fix, the commands execute correctly.
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 18:06
Message:
Logged In: YES
user_id=479790
Originator: NO
Use a list of arguments instead, and please remember to use raw strings or
double backslashes:
proc = subprocess.Popen([r"c:\Windows\system\ping.exe","localhost"],
shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
--
Comment By: tzellman (tzellman)
Date: 2007-05-07 14:20
Message:
Logged In: YES
user_id=1090960
Originator: YES
This could likely be rejected.
I realize a solution to this w/o modifying the Python source is to encase
the expression yourself in double quotes. So, the example given would look
like:
>>> import subprocess
>>> proc = subprocess.Popen('""c:\Windows\system\ping.exe" "localhost""',
shell=1, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
And that will work.
Sorry for any confusion.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1714451&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 11:50
Message generated for change (Comment added) made by gagenellina
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: Gabriel Genellina (gagenellina)
Date: 2007-05-07 18: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 17: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 14: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 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-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 11:50
Message generated for change (Comment added) made by gagenellina
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: Gabriel Genellina (gagenellina)
Date: 2007-05-07 22: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 18: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 18: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 17: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 14: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
