Serhiy Storchaka added the comment:
+ newline is '' or '\n', no translation takes place. If newline is
any\n
Non-escaped \n.
--
nosy: +storchaka
status: closed - open
___
Python tracker rep...@bugs.python.org
Georg Brandl added the comment:
Would be nice to be a bit more specific *where* that line comes from.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
___
Serhiy Storchaka added the comment:
Would be nice to be a bit more specific *where* that line comes from.
Modules/_io/textio.c, changesets 243ad1a6f638 and 083776adcacc.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
Serhiy Storchaka added the comment:
Oops, I got the wrong issue, sorry.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
___
Antoine Pitrou added the comment:
We should not convert \n with -u command line option or PYTHONUNBUFFERED was
set.
Why that? What do universal newlines have to do with buffering?
--
___
Python tracker rep...@bugs.python.org
Martin v. Löwis added the comment:
I wonder why this is a release blocker. It's a bug in Python 3.2, so why should
it block the release of 3.3 (it's not a regression).
If no complete solution is coming up, I recommend to revert all changes on this
issue, and reconsider after the 3.3 release.
Antoine Pitrou added the comment:
I wonder why this is a release blocker. It's a bug in Python 3.2, so
why should it block the release of 3.3 (it's not a regression).
It's a blocker because the fix broke a couple of tests.
And it's also a regression from 3.1 and 2.7.
--
Martin v. Löwis added the comment:
It's a blocker because the fix broke a couple of tests.
That cannot possibly be the explanation why haypo declared
it a blocker on 2012-08-01; the fix was only applied on
2012-08-04.
But I agree that it should block the release now; hence I
propose to roll
Atsuo Ishimoto added the comment:
Antoine Pitrou added the comment:
We should not convert \n with -u command line option or PYTHONUNBUFFERED was
set.
Why that? What do universal newlines have to do with buffering?
Man page of Python says
-u Force stdin, stdout and stderr to be
Antoine Pitrou added the comment:
Man page of Python says
-u Force stdin, stdout and stderr to be totally unbuffered. On
systems where it matters, also put stdin, stdout and stderr in
binary mode.
I don't know which version it is, but current 3.3 says:
“Force the
Roundup Robot added the comment:
New changeset bc4fdb758b8c by Antoine Pitrou in branch '3.2':
Fix CGI tests to take into account the platform's line ending (issue #13119)
http://hg.python.org/cpython/rev/bc4fdb758b8c
New changeset ee185c6b2880 by Antoine Pitrou in branch 'default':
Fix CGI
STINNER Victor added the comment:
Buildbots are happy, the issue can be closed again. Thanks Antoine.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
___
Atsuo Ishimoto added the comment:
I don't know which version it is, but current 3.3 says:
Ah, sorry, I thought I was reading latest Man page.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
Antoine Pitrou added the comment:
Windows buildbots now show failures in the test suite.
--
status: closed - open
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
Roundup Robot added the comment:
New changeset 4efad7fba42a by Antoine Pitrou in branch '3.2':
Fix test_sys under Windows (issue #13119)
http://hg.python.org/cpython/rev/4efad7fba42a
New changeset e4a87f0253e9 by Antoine Pitrou in branch 'default':
Merge universal newlines-related fixes (issue
Roundup Robot added the comment:
New changeset f8e435d6a801 by Antoine Pitrou in branch 'default':
Fix test_venv to work with universal newlines (issue #13119)
http://hg.python.org/cpython/rev/f8e435d6a801
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
test_httpservers still fails, it's the CGI tests...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
___
Atsuo Ishimoto added the comment:
Fix for test_httpservers
--
Added file: http://bugs.python.org/file26694/issue13119_httpserver.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
___
Atsuo Ishimoto added the comment:
Sorry, please ignore the patch 'issue13119_httpserver.patch' I posted above.
Behavior of -u commandline option in Python3.3 is differ than in Python 2.
We should not convert newline characters if -u specified? I'll investigate
more.
--
Atsuo Ishimoto added the comment:
We should not convert \n with -u command line option or PYTHONUNBUFFERED was
set.
Added a patch to fix error in test_httpservers.
--
Added file: http://bugs.python.org/file26695/issue13119_unbuffered.patch
___
Roundup Robot added the comment:
New changeset c55dbb84f3b4 by Victor Stinner in branch 'default':
Close #13119: use \r\n newline for sys.stdout/err on Windows
http://hg.python.org/cpython/rev/c55dbb84f3b4
--
nosy: +python-dev
resolution: - fixed
stage: - committed/rejected
status:
Roundup Robot added the comment:
New changeset 09408b990ca5 by Victor Stinner in branch '3.2':
Close #13119: use \r\n newline for sys.stdout/err on Windows
http://hg.python.org/cpython/rev/09408b990ca5
--
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
I wonder why print(1, file=sys.stderr) returns '1' instead of '1\n'.
I suppose that you mean returns '1\n' instead of '1'. This is a
major change between Python 2 and Python 3. Use print(1, end=' ') if
you want the same behaviour. See:
STINNER Victor added the comment:
It would be nice to fix this before Python 3.3 final.
@Georg: So, what do you think?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
___
Antoine Pitrou added the comment:
About the patch: why wouldn't you use newline = NULL in both cases?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
___
Atsuo Ishimoto added the comment:
On Fri, Aug 3, 2012 at 5:16 AM, STINNER Victor rep...@bugs.python.org wrote:
I wonder why print(1, file=sys.stderr) returns '1' instead of '1\n'.
I suppose that you mean returns '1\n' instead of '1'.
No, sorry for my lame wording.
In the test I submitted,
STINNER Victor added the comment:
On Windows, stdin, stdout and stderr are creates using TextIOWrapper(...,
newline=None).
In this case, TextIOWrapper._writenl is os.linesep and so '\r\n'.
Oh, I was wrong: stdin is created with newline=None, but stdout and stderr are
created with
Atsuo Ishimoto added the comment:
Test for this issue. Tested on Windows7, Ubuntu linux 12.04.
I wonder why print(1, file=sys.stderr) returns '1' instead of '1\n'.
But in Python2.7, print sys.stderr, 1 also returns '1',
so this might not be a problem.
--
Added file:
Atsuo Ishimoto added the comment:
I found 'more' command in Windows7 requires \r\n.
Python 2.7.3:
C:\python -c for i in range(5):print(i)|more
0
1
2
3
4
Python 3.3(trunk):
c:\src\cpython\PCbuildpython -c for i in range(5):print(i)|more
?
--
nosy: +ishimoto
M. Zilmer mzdkm...@gmail.com added the comment:
Just to make it clear: I have not observed any problems on the Windows terminal
(cmd) with \n newline, but at least Notepad does not break lines correctly if
only \n is used.
--
___
Python tracker
Changes by Florent Xicluna florent.xicl...@gmail.com:
--
nosy: +flox
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
___
___
Python-bugs-list
STINNER Victor victor.stin...@haypocalc.com added the comment:
I changed how newlines are handled on Windows to fix an issue with CGI: see the
issue #10841.
changeset: 67431:0933c3753a71
user:Victor Stinner victor.stin...@haypocalc.com
date:Fri Jan 07 18:47:22 2011 +
STINNER Victor victor.stin...@haypocalc.com added the comment:
print() uses PyFile_WriteString(\n, file) by default (if the end argument is
not set) to write the newline. TextIOWrapper.write(\n) replaces \n by
TextIOWrapper._writenl.
On Windows, stdin, stdout and stderr are creates using
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
If the output is redirected (e.g. into a file),
TextIOWrapper is created with line_buffering=False.
How does this affect the \r\n translation?
--
___
Python tracker rep...@bugs.python.org
New submission from M. Zilmer mzdkm...@gmail.com:
In 3.2.2 the newline for print() is \n on Windows, and not \r\n as expected.
In 3.1.4 the newline is \r\n.
OS is Win 7, and tried on both 32 and 64 bit.
Small example with output is attached.
--
components: Windows
files: newline.py
Changes by M. Zilmer mzdkm...@gmail.com:
Added file: http://bugs.python.org/file23331/newline_3.1.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
___
Changes by M. Zilmer mzdkm...@gmail.com:
Added file: http://bugs.python.org/file23332/newline_3.2.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
___
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
To people who open the file in their browser: text files are very similar, but
newline_3.1.txt has CRLF line endings and newline_3.2.txt has LF line endings.
M.Z, how did you obtain them? did you start a subprocess?
--
nosy:
M. Zilmer mzdkm...@gmail.com added the comment:
Hi Amaury,
The two text files were obtained through redirection in Windows, so I simply
ran the newline.py file with:
... C:\Python31\python.exe newline.py newline_3.1.txt
... C:\Python32\python.exe newline.py newline_3.2.txt
Best
39 matches
Mail list logo
