"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
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
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'
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
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
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
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
"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 indi
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 correc
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
>>> 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 cu
"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 p
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 newline-wit
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.
Th
17 matches
Mail list logo
