Changes by Josiah Carlson :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue1370380>
___
___
Python-bugs-
Josiah Carlson added the comment:
Fixed the close() call and committed to trunk. Python 2.6 tests pass
with the new version of the library. Calling it good :) .
--
keywords: -needs review
resolution: -> accepted
status: open ->
Josiah Carlson added the comment:
I fixed some bugs with my patch, merged in Giampaolo's tests and
documentation, and altered the API to match Giampaolo's API almost
completely.
This new version differs from Giampaolo's patch only in underlying
implementation; this uses a mo
Changes by Josiah Carlson :
Removed file: http://bugs.python.org/file13238/scheduler_partial.patch
___
Python tracker
<http://bugs.python.org/issue1641>
___
___
Python-bug
Josiah Carlson added the comment:
Good point Giampaolo. Fixed and committed.
--
___
Python tracker
<http://bugs.python.org/issue1161031>
___
___
Python-bug
Josiah Carlson added the comment:
The spare 512 values are for code that I expect no one is actually
using.
In terms of increasing the buffer size from 4096 to something larger,
that can be done, but I think that more than just a 10mbit switched lan
test should be performed. I would tend
Josiah Carlson added the comment:
Just to make this clear, Aleksi is proposing close() should be called
automatically by some higher-level functionality whether a user has
overridden handle_close() or not.
With the updated asyncore warning suppression stuff, overriding
handle_close() for
Josiah Carlson added the comment:
IIRC, there was a threat to remove asyncore because there were no
maintainers, no one was fixing bugs, no one was improving it, and no one
was really using it (I believe the claim was that people were just using
Twisted). The patches that were ultimately
Josiah Carlson added the comment:
I'm happy to let them know proposed changes now that I know issues
exist, but you have to admit that they were pretty under-the-radar until
4-5 months *after* 2.6 was released. If there is a mailing address that
I can send proposed changes to asynco
Josiah Carlson added the comment:
Here's a question: How do we fix 2.6?
>From what I've read, the only answer I've heard is "revert to 2.5 in
2.6.2", which has the same issues as adding True/False in 2.2 .
I agree that Zope not working in 2.6 is a problem, I agree
Josiah Carlson added the comment:
To be wholly clear about the issues, it's not with asyncore, the core
asynchronous
library, it's with asynchat and the internal changes to that. Any changes to
asyncore
were to fix corner cases and exceptions. No API, internal or external wa
Josiah Carlson added the comment:
I think that catching one more potential failure modes is reasonable.
I'm probably going to apply a variant of this patch to pull the sequence
into a frozenset for quick lookups, and so that we don't need to keep
updating two different places i
Josiah Carlson added the comment:
I'm not defending the documentation, I'm merely reposting it.
The documentation for asyncore says, "The full set of methods that can
be overridden in your subclass follows:"
The documentation for asynchat says, "To make practical
Josiah Carlson added the comment:
Looking at trunk, it seems like one reasonable option is to swap the
order of handle_close() and handle_expt_event() testing and calls. That
would keep all reading/writing before handle_close(), which should be
correct
Josiah Carlson added the comment:
It would seem that we need to be more defensive in our calls. We need
to check to make sure that the socket isn't closed before calling
read/write/expt events.
--
___
Python tracker
<http://bugs.py
Josiah Carlson added the comment:
Mark, try this:
if flags & select.POLLIN and (obj.connected or obj.accepting):
obj.handle_read_event()
if flags & select.POLLOUT and obj.connected:
obj.handle_write_event()
if flags & select
Josiah Carlson added the comment:
Try getting rid of the "and" clause in the select.POLLIN .
--
___
Python tracker
<http://bugs.python.org/issue5798>
___
__
Josiah Carlson added the comment:
To be clear, make the first test read...
if flags & select.POLLIN:
obj.handle_read_event()
--
___
Python tracker
<http://bugs.python.org/is
Josiah Carlson added the comment:
I went ahead and plugged my mac in (which reminded me of why I unplugged
it in the first place), and I'm able to reproduce your error in the test
after my proposed modifications.
One thing to remember is that the test is broken; we rely on a
.conn
Josiah Carlson added the comment:
As an aside, I was testing against trunk, not 3.1b1 .
--
___
Python tracker
<http://bugs.python.org/issue5798>
___
___
Pytho
Josiah Carlson added the comment:
One of the issues with using the method that Giampaolo describes, which
I explained to him, is that generally if someone sends you data, you
want to receive it. You can get both data and the signal that someone
disconnected, in particular, with asynchat&#
Josiah Carlson added the comment:
Ok, so I was running "test_asyncore" and not "test_asynchat".
The issue on OS X is that when a new socket is connecting, select.poll()
shows the socket as being writable when it first connects, but using my
variant, .connected is False wh
Changes by Josiah Carlson :
Removed file: http://bugs.python.org/file13915/asyncore_fix_mac.patch
___
Python tracker
<http://bugs.python.org/issue5798>
___
___
Python-bug
Changes by Josiah Carlson :
Removed file: http://bugs.python.org/file13918/unnamed
___
Python tracker
<http://bugs.python.org/issue5798>
___
___
Python-bugs-list mailin
Josiah Carlson added the comment:
Here's an option that doesn't use .connected, which some people have
expressed distaste for.
def readwrite(obj, flags):
try:
if flags & select.POLLIN:
obj.handle_read_event()
if flags &a
Josiah Carlson added the comment:
You can probably close this unless someone says otherwise. asyncore/asynchat
work in Python 3.0+, as long as only bytes are passed.
As of right now, this is a request for documentation stating "you can only
send/receive bytes"...which may be imp
Josiah Carlson added the comment:
If it's failing, and asyncore is still in 3.1, then I would argue yes.
I'll submit a fix to trunk and 3.1 based on my version below (unless
anyone has any outstanding concerns, or believes that it doesn't
Changes by Josiah Carlson :
Removed file: http://bugs.python.org/file13934/asyncore_fix_mac_2.patch
___
Python tracker
<http://bugs.python.org/issue5798>
___
___
Pytho
Josiah Carlson added the comment:
Fixed in trunk in 73182, fixed in py3k in 73183.
Closing as fixed.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Josiah Carlson added the comment:
I installed 3.1rc1 on my OS X (10.5.?) machine, updated asynchat, and ran
the test with and without my change. Without my change, it breaks in the
way described numerous times. With my change, it seems to work fine on OS
X, linux, and Windows for me
Josiah Carlson added the comment:
The other patch is more correct. Closing.
--
resolution: -> duplicate
status: open -> closed
superseder: -> SimpleHTTPServer directory-indexing "bug" fix
___
Python tracker
<http://bugs.p
Josiah Carlson added the comment:
Okay, I'm sorry for falling asleep at the wheel on this. At this point, I don't
expect this to go in for 3.5 - but if it has a chance, I'll do what I need to
do to get it there. Let me know.
I agree with the .communicate() not raising on b
Josiah Carlson added the comment:
I'm going to be honest; seeing None being returned from a pipe read feels
*really* broken to me. When I get None returned from an IO read operation, my
first instinct is "there can't be anything else coming, why else would it
return None?&q
Josiah Carlson added the comment:
Non-blocking IO returning a None on "no data currently available" is new to me.
It is new to me simply because I don't recall it ever happening in Python 2.x
with any socket IO that I ever dealt with, and socket IO is my primary source
for
101 - 134 of 134 matches
Mail list logo
