Hello,
I've been doing some tests on removing the GIL, and it's becoming clear that
some basic changes to the garbage collector may be needed in order for this
to happen efficiently. Reference counting as it stands today is not very
scalable.
I've been looking into a few options, and I'm leaning
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
[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
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 i
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
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 p
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
[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
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
15 matches
Mail list logo