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
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
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" <[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
>>> 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
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
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
"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
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
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
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
"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
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]
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,
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'
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
"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
17 matches
Mail list logo
