[EMAIL PROTECTED] wrote:
> I've been thinking about this some more (in lieu of actually writing up any
> sort of proposal ;-) and I'm not so sure it would be all that useful.
Yes, despite being the one who suggested it, I've come to
the same conclusion myself. The problem should really be
addresse
Nick Maclaren wrote:
> I have implemented both of those two models
> on systems that are FAR more different than most people can imagine.
> Both work, and neither causes confusion. The C/Unix/Python one does.
Now I'm not sure what *you* mean by the C/Unix/Python
model. As far as newlines are conc
[EMAIL PROTECTED] wrote:
>
> I've been thinking about this some more (in lieu of actually writing up any
> sort of proposal ;-) and I'm not so sure it would be all that useful. If
> you've opened a file in text mode you should only be writing newlines as
> '\n' anyway. If you want to translate a
Greg> Maybe there should be a universal newlines mode defined for output
Greg> as well as input, which translates any of "\r", "\n" or "\r\n"
Greg> into the platform line ending.
Skip> I'd be open to such a change. Principle of least surprise?
Guido> The symmetry isn't as st
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> I don't see how this is different from Unix/C "\n" being
> an atomic newline character.
Have you used systems with the I/O models I referred to (or ones
with newlines being out-of-bound data)?
> If you're saying that BCPL is better because it defines
> s
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
"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, 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
On 26/09/2007, Dino Viehland <[EMAIL PROTECTED]> 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 interna
Dino Viehland wrote:
>>Why don't you just use binary mode then?
>
> That just flips the problem to the other side.
Seems to me that IronPython really needs two string
types, "Python string" and ".NET string", with automatic
conversion when crossing a boundary between Python
code and .NET code.
-
[moving to python-3000]
The symmetry isn't as strong as you suggest, but I agree it would be a
useful feature. Would you mind filing a Py3k feature request so we
don't forget?
A proposal for an API given the existing newlines=... parameter
(described in detail in PEP 3116) would be even better.
> This I don't understand. Why don't you just use binary mode then?
> At least for Python 2.x, the *only* difference between text and
> binary mode is the treatment of line endings.
That just flips the problem to the other side. Now if I have a
Python library that I'm mixing w/ .NET code I need t
> 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.
Here you misunderstand - that's only the case when the
Greg> Maybe there should be a universal newlines mode defined for output
Greg> as well as input, which translates any of "\r", "\n" or "\r\n"
Greg> into the platform line ending.
I thought that's the way it was supposed to work, but it clearly doesn't:
>>> f = open("test.txt", "w
Dino Viehland wrote:
> When writing a string in text mode that contains \r\n we both write \r\r\n
Maybe there should be a universal newlines mode defined for
output as well as input, which translates any of "\r", "\n"
or "\r\n" into the platform line ending.
Although I suspect that a string conta
7;\r', '') is the way to go we can advice our users of the behavior
when interoperating w/ APIs that return \r\n in strings.
-Original Message-
From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 3:01 PM
To: Dino Viehland
Cc: py
On 9/26/07, Dino Viehland <[EMAIL PROTECTED]> wrote:
> We ran into an interesting user-reported issue w/ IronPython and the way
> Python writes to files and I thought I'd get python-dev's opinion.
>
> When writing a string in text mode that contains \r\n we both write \r\r\n
> because the default
> This works great as long as you stay within an entirely Python world.
> Because Python uses \n for everything internally
I think you misunderstand fairly significantly how this all works
together. Python does not use \n "for everything internally". Python
is well capable of representing \r separ
We ran into an interesting user-reported issue w/ IronPython and the way Python
writes to files and I thought I'd get python-dev's opinion.
When writing a string in text mode that contains \r\n we both write \r\r\n
because the default write mode is to replace \n with \r\n. This works great as
21 matches
Mail list logo
