Mike Coleman added the comment:
Just to confirm, the real problem here was that tiny packets were being
sent out by default, and the obvious fix (altering ac_out_buffer_size)
didn't work.
Looking at the code, it appears that the change by Josiah Carlson
(#64062) causes ac_out_buffer
Mike Coleman added the comment:
My original report didn't mention it specifically, but I believe I was
hitting the FD_SETSIZE limit that Frank mentioned. (Thanks for working
on this!)
--
___
Python tracker
<http://bugs.python.org/i
Mike Coleman added the comment:
I also ran into this bug.
In my case I'm able to work around this by "reserving" some fds at the
start of my program (open 20 reserved fds, open 2000 real fds, close 20
reserved fds), but this is both a kludge and not a general solution.
Pro
Mike Coleman added the comment:
Also, as with the other python versions, notice that the error status is
EXIT_SUCCESS (which it should not be).
___
Python tracker
<http://bugs.python.org/issue5
New submission from Mike Coleman :
$ python3.0 -c 'print((1, 2, 3))' > /dev/full || echo error status
$
This command gives no indication whatsoever that anything has gone
wrong. Following this with strace demonstrates that the interpreter is
in fact ignoring these errors:
2589
New submission from Mike Coleman :
$ python2.6 -c 'print 1, 2, 3' > /dev/full || echo error status
close failed in file object destructor:
Error in sys.excepthook:
Original exception was:
$
It seems like something other than blank lines should be printed here.
Mike Coleman added the comment:
Oops, I should have used the old python print syntax. Nonetheless, the
behavior is the same:
$ python2.5 -c 'print 1, 2, 3' > /dev/full || echo error status
close failed: [Errno 28] No space left on device
$
--
components: +Int
New submission from Mike Coleman :
$ python2.5 -c 'print((1, 2, 3))' > /dev/full || echo error status
close failed: [Errno 28] No space left on device
$
The above sequence should also output 'error status' before the next
prompt. That is, python should not be returni
Mike Coleman added the comment:
I'll go down to the cemetery and see if I can dig one up. :-)
All of our Tru64 machines have been powered-down for over three years
now, so as far as I'm concerned you can mark this one as no longer relevant.
New submission from Mike Coleman :
I was thrown by the "Failed to find the necessary bits to build these
modules" message at the end of newer Python builds, and thought that
this indicated that the Python executable itself was not built.
That's arguably stupidity on my part,
Mike Coleman <[EMAIL PROTECTED]> added the comment:
Okay. For what it's worth, note that my original 2004 patch for this
(#988761) is completely backward compatible (a flag must be set in the
call to get the new behavior).
___
Python trac
Mike Coleman <[EMAIL PROTECTED]> added the comment:
I think it's probably both. The original design was incorrect, though
this probably wasn't apparent to the designer. But as a significant
user of 're', it really stands out as a problem.
Mike Coleman <[EMAIL PROTECTED]> added the comment:
I don't want to discourage you, but #852532, which is essentially the
same bug report, was closed--without explanation--as 'wont fix' in
April, after four-plus years. I wish you good luck--this is an
important and irritati
Changes by Mike Coleman <[EMAIL PROTECTED]>:
--
nosy: +mkc
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3262>
___
___
Python-bugs
Mike Coleman <[EMAIL PROTECTED]> added the comment:
I'd feel better about this bug being 'wont fix'ed if I had a sense that
several people considered the patch and thought that it sucked. At the
moment, it seems more like it just fell off of the end without ever
being s
Mike Coleman <[EMAIL PROTECTED]> added the comment:
[Tracker bounced this the first time...]
> I haven't run it, but just browsing the trunk source, it appears to
> still be present. In fact, asynchat.py and asyncore.py have
> apparently not been changed in two years. A
Mike Coleman added the comment:
The other place I see the constant is in asyncore.py:
class dispatcher_with_send(dispatcher):
def __init__(self, sock=None, map=None):
dispatcher.__init__(self, sock, map)
self.out_buffer = ''
def initiate_send(self):
Mike Coleman added the comment:
The value is used there, but this is not effective in causing larger
packets to be sent, which I noticed by watching with strace. I think
the reason for this is that 'refill_buffer' will only make at most one
call to simple_producer.more, and that
New submission from Mike Coleman:
In asynchat, 'push' doesn't specify 'buffer_size', so the default of 512
is used. This is bogus and causes poor performance--it should use the
value of 'ac_out_buffer_size' instead.
--
components: Library (Lib)
Mike Coleman added the comment:
Well, I think we can conclude that it's expected by *them*. :-) I
still find it surprising, and it somewhat lessens the utility of
re.split for my use cases. (I think re.finditer may also suffer from
the same problem, but I don't recall.)
If you l
20 matches
Mail list logo
