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 PRECISELY
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
standard
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 strong as
[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
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
[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 written out
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
Michael
I was using httplib to power my xml rpc script.
I had problems when I wanted to use SSL and I got this error:
File /usr/lib/python2.5/httplib.py, line 1109, in recv
return self._ssl.read(len)
socket.sslerror: (8, 'EOF occurred in violation of protocol')
I figured out this was because of
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 used by
On 9/30/07, Richie Ward [EMAIL PROTECTED] wrote:
I was using httplib to power my xml rpc script.
I had problems when I wanted to use SSL and I got this error:
File /usr/lib/python2.5/httplib.py, line 1109, in recv
return self._ssl.read(len)
socket.sslerror: (8, 'EOF occurred in
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
[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
addressed
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 and
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're going to
14 matches
Mail list logo
