Paul Moore [EMAIL PROTECTED] wrote:
OK, so far so good - although I'm not *quite* sure there's a
self-consistent definition of code that only uses \n. I'll assume
you mean code that has a concept of lines, that lines never contain
anything other than text (specifically, neither \r or \n can
On 9/29/07, Nick Maclaren [EMAIL PROTECTED] wrote:
Paul Moore [EMAIL PROTECTED] wrote:
OK, so far so good - although I'm not *quite* sure there's a
self-consistent definition of code that only uses \n. I'll assume
you mean code that has a concept of lines, that lines never contain
On 9/28/07, Thomas Heller [EMAIL PROTECTED] wrote:
Thomas Wouters schrieb:
If you re-eally need to check something into the trunk that re-eally
must not be merged into py3k, but you're afraid it's not going to be
obvious to the merger, please record the change as 'merged' using
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,
If the differences are few, I prefer that you insert some conditionals
that attach different functions based on the version number. That way
we can keep a single version of the source that works on all of the
pythons.
Raymond
On Sep 29, 2007, at 8:26 AM, Thomas Wouters [EMAIL PROTECTED]
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
Guido van Rossum [EMAIL PROTECTED] wrote:
Have you looked at Py3k at all, especially PEP 3116 (new I/O)?
No.
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
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
Nick Maclaren 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.
If you want universal newlines, you just have
On 9/29/07, Nick Maclaren [EMAIL PROTECTED] wrote:
Now, BCPL was an ancestor of C, but always was a more portable
language (i.e. it didn't start with a specific operating system in
mind), and used/uses a rather better model. In this, line separators
are atomic - e.g. '\f' is
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.
17 matches
Mail list logo
