Guido van Rossum [EMAIL PROTECTED] wrote:
Does anyone else have the feeling that discussions with Mr. MacLaren
don't usually bear any fruit?
Yes. I do. My ability to predict the (technical) future is good;
my ability to persuade people of it is almost non-existent.
However, when an almost
Greg Ewing [EMAIL PROTECTED] wrote:
I don't know PRECISELY what you mean by universal newlines mode
I mean precisely what Python means by the term: any of
\r, \n or \r\n represent a newline, and no distinction
is made between them.
Excellent. While this over-simplifies the issue, let's
On 01/10/2007, Nick Maclaren [EMAIL PROTECTED] wrote:
So, damn the outside system, EXACTLY what does Python mean by
such characters, and EXACTLY what uses of them are discouraged
as having unspecified meanings? If we could get an answer to
that precisely enough to write a parse tree with all
Paul Moore [EMAIL PROTECTED] wrote:
So, damn the outside system, EXACTLY what does Python mean by
such characters, and EXACTLY what uses of them are discouraged
as having unspecified meanings? If we could get an answer to
that precisely enough to write a parse tree with all terminals
Michael Foord wrote:
Steven Bethard wrote:
On 9/29/07, Michael Foord [EMAIL PROTECTED] wrote:
Terry Reedy wrote:
There are two normal ways for internal Python text to have \r\n:
1. Read from a file with \r\r\n. Then \r\r\n is correct output (on the
same platform).
2. Intentially
Steve Holden wrote:
Michael Foord wrote:
Steven Bethard wrote:
On 9/29/07, Michael Foord [EMAIL PROTECTED] wrote:
Terry Reedy wrote:
There are two normal ways for internal Python text to have \r\n:
1. Read from a file with \r\r\n. Then \r\r\n is correct
Well, it's an OS level difference and I thought that in general Python
*doesn't* try to protect you from OS differences.
I think that's the key point. In general, Python tries to present a
translucent interface to the OS in which OS differences can show
through, in contrast to other languages
Guido van Rossum wrote:
The best solution for IronPython is probably to have the occasional
wrapper around .NET APIs that translates between \r\n and \n on the
boundary between Python and .NET;
That's probably true. I was responding to the notion
that IronPython shouldn't need any wrappers. To
Nick Maclaren wrote:
if Python's own
interpretation is ambiguous, it is a sure recipe for different
translators being incompatible,
Python's own interpretation is not ambiguous. The
problem at hand is people wanting to use some random
mixture of Python and .NET conventions.
--
Greg Ewing,
Michael Foord wrote:
It is also different from how libraries like wxPython behave - where
they *don't* protect you from OS differences and if a textbox has '\r\n'
line endings - that is what you get...
That sounds like an undesirable deficiency of those library
wrappers, especially
Nick Maclaren [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| The question is independent of what the outside system believes a
| text file should look like, and is solely what Python believes a
| sequence of characters should mean. For example, does 'A\r\nB'
| mean that B is
Does anyone else have the feeling that discussions with Mr. MacLaren
don't usually bear any fruit?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
Greg Ewing [EMAIL PROTECTED] wrote:
Grrk. That's the problem. You don't get back what you have written
You do as long as you *don't* use universal newlines mode
for reading. This is the best that can be done, because
universal newlines are inherently ambiguous.
I don't know PRECISELY
Michael Actually, I usually get these strings from Windows UI
Michael components. A file containing '\r\n' is read in with '\r\n'
Michael being translated to '\n'. New user input is added containing
Michael '\r\n' line endings. The file is written out and now contains a
[EMAIL PROTECTED] wrote:
Michael Actually, I usually get these strings from Windows UI
Michael components. A file containing '\r\n' is read in with '\r\n'
Michael being translated to '\n'. New user input is added containing
Michael '\r\n' line endings. The file is written out
Michael Foord [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Michael Actually, I usually get these strings from Windows UI
Michael components. A file containing '\r\n' is read in with '\r\n'
Michael being translated to '\n'. New user input is added containing
Michael
Nick Maclaren wrote:
I don't know PRECISELY what you mean by universal newlines mode
I mean precisely what Python means by the term: any of
\r, \n or \r\n represent a newline, and no distinction
is made between them.
You only need to use that if you don't know what convention
is being used by
Michael Foord wrote:
We stick to using the .NET file I/O and so don't
have a problem. The only time it is an issue for us is our tests, where
we have string literals in our test code (where new lines are obviously
'\n')
If you're going to do that, you really need to be consistent
about and
On 9/30/07, Greg Ewing [EMAIL PROTECTED] wrote:
Michael Foord wrote:
We stick to using the .NET file I/O and so don't
have a problem. The only time it is an issue for us is our tests, where
we have string literals in our test code (where new lines are obviously
'\n')
If you're going to
Guido van Rossum wrote:
[snip..]
Python *does* have its own I/O model. There are binary files and text
files. For binary files, you write bytes and the semantic model is
that of an array of bytes; byte indices are seek positions.
For text files, the contents is considered to be Unicode,
Michael Foord [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Guido van Rossum wrote:
[snip first part of nice summary of Python i/o model]
| The other translation deals with line endings. Upon input, any of
| \r\n, \r, or \n is translated to a single \n by default (this is nhe
Terry Reedy wrote:
Michael Foord [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Guido van Rossum wrote:
[snip first part of nice summary of Python i/o model]
| The other translation deals with line endings. Upon input, any of
| \r\n, \r, or \n is translated to a single \n
On 9/29/07, Michael Foord [EMAIL PROTECTED] wrote:
Terry Reedy wrote:
There are two normal ways for internal Python text to have \r\n:
1. Read from a file with \r\r\n. Then \r\r\n is correct output (on the
same platform).
2. Intentially put there by a programmer. If s/he also chooses
Steven Bethard wrote:
On 9/29/07, Michael Foord [EMAIL PROTECTED] wrote:
Terry Reedy wrote:
There are two normal ways for internal Python text to have \r\n:
1. Read from a file with \r\r\n. Then \r\r\n is correct output (on the
same platform).
2. Intentially put there by a
On 9/29/07, Michael Foord [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
On 9/29/07, Michael Foord [EMAIL PROTECTED] wrote:
Terry Reedy wrote:
There are two normal ways for internal Python text to have \r\n:
1. Read from a file with \r\r\n. Then \r\r\n is correct output (on the
Steven Bethard wrote:
On 9/29/07, Michael Foord [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
On 9/29/07, Michael Foord [EMAIL PROTECTED] wrote:
Terry Reedy wrote:
There are two normal ways for internal Python text to have \r\n:
1. Read from a file with \r\r\n.
Actually, I usually get these strings from Windows UI components. A file
containing '\r\n' is read in with '\r\n' being translated to '\n'. New
user input is added containing '\r\n' line endings. The file is written
out and now contains a mix of '\r\n' and '\r\r\n'.
Out of curiosity, why
Michael Foord [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Terry Reedy wrote:
| There are two normal ways for internal Python text to have \r\n:
| 1. Read from a file with \r\r\n. Then \r\r\n is correct output (on the
| same platform).
| 2. Intentially put there by a
Michael Foord wrote:
One of the great things about IronPython is that you don't *need* any
wrappers - you access .NET objects natively
But it seems that you really *do* need wrappers to
deal with the line endings problem, whether they're
provided automatically or you it yourself manually.
, September 26, 2007 3:01 PM
To: Dino Viehland
Cc: python-dev@python.org
Subject: Re: [Python-Dev] New lines, carriage returns, and Windows
This works great as long as you stay within an entirely Python world.
Because Python uses \n for everything internally
I think you
, September 26, 2007 3:15 PM
To: Dino Viehland
Cc: python-dev@python.org
Subject: Re: [python] Re: [Python-Dev] New lines, carriage returns, and Windows
Dino Viehland wrote:
My understanding is that users can write code that uses only \n and Python
will write the end-of-line character(s
PM
To: Dino Viehland
Cc: python-dev@python.org
Subject: Re: [python] Re: [Python-Dev] New lines, carriage returns, and
Windows
Dino Viehland wrote:
My understanding is that users can write code that uses only \n and Python
will write the end-of-line character(s) that are appropriate
32 matches
Mail list logo
