"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 al
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
http://mail.python.org/mailman/listinfo
"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 sep
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 cross-p
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,
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.
> 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 langua
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 fil
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 pla
"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
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
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 th
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'
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
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 u
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
>
[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 writte
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
Mic
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 PRE
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
"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
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
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,
Dino Viehland wrote:
> And if this is fine for you, given that you may have the largest WinForms /
> IronPython code base, I tend to think the replace may be reasonable. But we
> have had someone get surprised by this behavior.
>
It is a slight impedance mismatch between Python and Windows -
And if this is fine for you, given that you may have the largest WinForms /
IronPython code base, I tend to think the replace may be reasonable. But we
have had someone get surprised by this behavior.
-Original Message-
From: Michael Foord [mailto:[EMAIL PROTECTED]
Sent: Wednesday, Sept
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 for the platform
> when writing to a file. That's what I meant by uses \n for everything
> internally.
>
> But if you write \r\n to a
32 matches
Mail list logo
