Change by Josiah Carlson :
--
nosy: -josiahcarlson
___
Python tracker
<https://bugs.python.org/issue1509060>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Josiah Carlson :
--
nosy: -josiahcarlson
___
Python tracker
<https://bugs.python.org/issue1572968>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Josiah Carlson :
--
nosy: -josiahcarlson
___
Python tracker
<https://bugs.python.org/issue1453973>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Josiah Carlson :
--
nosy: -josiahcarlson
___
Python tracker
<https://bugs.python.org/issue3783>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Josiah Carlson :
--
nosy: -josiah.carlson, josiahcarlson
___
Python tracker
<https://bugs.python.org/issue13451>
___
___
Python-bugs-list mailin
Change by Josiah Carlson :
--
nosy: -josiahcarlson
___
Python tracker
<https://bugs.python.org/issue1043134>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Josiah Carlson :
--
nosy: -josiahcarlson
___
Python tracker
<https://bugs.python.org/issue35913>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Josiah Carlson :
--
nosy: -josiahcarlson
___
Python tracker
<https://bugs.python.org/issue13372>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Josiah Carlson :
--
nosy: -josiahcarlson
___
Python tracker
<https://bugs.python.org/issue6911>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Josiah Carlson :
--
nosy: -josiah.carlson, josiahcarlson
___
Python tracker
<https://bugs.python.org/issue4277>
___
___
Python-bugs-list mailin
Change by Josiah Carlson :
--
nosy: -josiahcarlson
___
Python tracker
<https://bugs.python.org/issue1442493>
___
___
Python-bugs-list mailing list
Unsubscribe:
Josiah Carlson added the comment:
Someone else can resurrect this concept and/ore patch if they care about this
feature. Best of luck to future readers.
--
stage: test needed -> resolved
status: open -> closed
___
Python tracker
Change by Josiah Carlson :
--
nosy: -josiahcarlson
___
Python tracker
<https://bugs.python.org/issue1260171>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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:
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:
First, with the use of Overlapped IO on Windows, BlockingIOError should never
come up, and we don't even handle that exception.
As for BrokenPipeError vs. EOF; while we do treat them more or less the same,
we aren't killing the process or reportin
Josiah Carlson added the comment:
I submitted an issue to the tulip/asyncio bug tracker:
https://code.google.com/p/tulip/issues/detail?id=170
And I am uploading a new patch that only includes non-tulip/asyncio related
changes, as tulip/asyncio changes will eventually be propagated to Python
Josiah Carlson added the comment:
First off, thank you everyone who has reviewed and commented so far. I very
much appreciate your input and efforts.
Does anyone have questions, comments, or concerns about the patch? If no one
mentions anything in the next week or so, I'll ping the
Josiah Carlson added the comment:
Richard: short timeouts are no longer an issue. Nothing to worry about :)
--
___
Python tracker
<http://bugs.python.org/issue1191
Josiah Carlson added the comment:
Victor, I addressed the majority of your comments except for a couple stylistic
pieces. Your annoyance with the short poll time for Windows made me re-read the
docs from MS, which made me realize that my interpretation was wrong. It also
made me confirm
Changes by Josiah Carlson :
Added file: http://bugs.python.org/file34861/subprocess_5.patch
___
Python tracker
<http://bugs.python.org/issue1191964>
___
___
Python-bug
Josiah Carlson added the comment:
I ended up eliminating the overlapped IO cancel call on Windows. Better to be
correct than to minimize internal state. Instead, we keep a reference to the
overlapped IO object, and any attempts to write to the child stdin before the
previous overlapped IO
Josiah Carlson added the comment:
No, the problem is that that ov.cancel() will attempt to cancel the IO, but a
subsequent ov.getresult(True) doesn't always return what was *actually* written
to the pipe unless you explicitly wait for the result to be available. But even
if you expli
Josiah Carlson added the comment:
I added the chunking for Windows because in manual testing before finishing the
patch, I found that large sends on Windows without actually waiting for the
result can periodically result in zero data sent, despite a child process that
wants to read.
Looking
Josiah Carlson added the comment:
Submitting an updated patch addressing Giampaolo's comments.
--
Added file: http://bugs.python.org/file34774/subprocess_2.patch
___
Python tracker
<http://bugs.python.org/issu
Josiah Carlson added the comment:
Should have uploaded this yesterday, but I got caught up with typical weekend
activities. The docs probably need more, and I hear that select.select() is
disliked, so that will probably need to be changed too.
--
Added file: http://bugs.python.org
Josiah Carlson added the comment:
All of the standard tests plus another few that I added all pass on Windows and
Linux. I've got some cleanup and a couple more tests to add tomorrow, then I'll
post a patch.
I ended up not using any overlapped IO cancellation in the Windows
Josiah Carlson added the comment:
Quick update before I head to bed.
Thank you for the input, I had gotten the individual async calls working a
couple days ago, and I was just working to replace the communicate() method for
Windows.
Yes, I'm using asyncio._overlapped, though asyncio
Josiah Carlson added the comment:
Had some time to work on this today.
I was missing something in my earlier versions of the code, and have managed to
get overlapped IOs to work, so at least I'm not quite so far behind the dozen
or so core developers who know more about the Windows p
Changes by Josiah Carlson :
--
versions: +Python 3.5 -Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list m
Josiah Carlson added the comment:
Due to some rumblings over on the mentors list and python-dev, this is now
getting some love.
Guido has stated that something should make it into the subprocess module for
3.5 in this email:
https://groups.google.com/d/msg/dev-python/I6adJLIjNHk/Usrvxe_PVJIJ
Josiah Carlson added the comment:
Giampaolo pinged me over email...
These additional conditions look good, and should be targeted for 3.3 .
Thank you :)
--
nosy: +josiahcarlson
___
Python tracker
<http://bugs.python.org/issue11
Josiah Carlson added the comment:
Some prodding from Giampaolo got me to pull out and simplify the sched.py
changes here: issue8684 .
That should be sufficient to add scheduling behavior into async socket servers
or otherwise.
--
___
Python
New submission from Josiah Carlson :
This patch is against Python trunk, but it could be easily targeted for Python
3.2 . It is meant to extract the scheduler updates from issue1641 without
mucking with asyncore. It's reach is reduced and simplified, which should make
maintenance
Josiah Carlson added the comment:
The suggested documentation changes sound good to me. Those items that aren't
documented may need a note that they are deprecated and will be removed in the
future, but I'd consider that optional.
--
Josiah Carlson added the comment:
I'm not a big fan of the names, but as long as the functionality exists,
people can easily alias them as necessary.
I've not actually looked at the patch, but as long as it does what it
says it does, it looks good.
My only question, does it make
Josiah Carlson added the comment:
handle_expt_event was removed in the test classes because it is no
longer being used by any of the tests. None of them send OOB data (also
known as priority data), so handle_expt_event should never be called.
When I have a chance to compare your patch to
Changes by Josiah Carlson :
Removed file: http://bugs.python.org/file14585/asyncore_fix_refused-2.patch
___
Python tracker
<http://bugs.python.org/issue6550>
___
___
Pytho
Changes by Josiah Carlson :
Removed file: http://bugs.python.org/file14581/asyncore_fix_refused.patch
___
Python tracker
<http://bugs.python.org/issue6550>
___
___
Pytho
Josiah Carlson added the comment:
Originally, handle_expt_event() was described as "handles OOB data or
exceptions", but over-using handle_expt_event() as an error/close
handler is a bad idea. The function asyncore.readwrite() (called by
asyncore.poll2()) does the right
Josiah Carlson added the comment:
Firstly, it expects that handle_expt_event() is for handling exceptional
conditions. This is not the case. handle_expt_event() is meant for
handling "OOB" or "priority" data coming across a socket. FTP and some
other protocols use th
Josiah Carlson added the comment:
The attached patch cleans up the remnants of the "handle_expt is for
exceptions", which isn't the case, as well as makes the "connection
refused" fix actually work on Windows. Nirs, could you verify this on
*nix?
--
as
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:
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:
Fixed in trunk in 73182, fixed in py3k in 73183.
Closing as fixed.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
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:
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
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:
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
Changes by Josiah Carlson :
Removed file: http://bugs.python.org/file13918/unnamed
___
Python tracker
<http://bugs.python.org/issue5798>
___
___
Python-bugs-list mailin
Changes by Josiah Carlson :
Removed file: http://bugs.python.org/file13915/asyncore_fix_mac.patch
___
Python tracker
<http://bugs.python.org/issue5798>
___
___
Python-bug
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
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:
As an aside, I was testing against trunk, not 3.1b1 .
--
___
Python tracker
<http://bugs.python.org/issue5798>
___
___
Pytho
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:
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:
Try getting rid of the "and" clause in the select.POLLIN .
--
___
Python tracker
<http://bugs.python.org/issue5798>
___
__
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
Good point Giampaolo. Fixed and committed.
--
___
Python tracker
<http://bugs.python.org/issue1161031>
___
___
Python-bug
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:
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
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 ->
Changes by Josiah Carlson :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue1370380>
___
___
Python-bugs-
Changes by Josiah Carlson :
Removed file: http://bugs.python.org/file13516/async_no_warn.patch
___
Python tracker
<http://bugs.python.org/issue1161031>
___
___
Python-bug
Josiah Carlson added the comment:
You are right. Handling OOB data is within the "exceptional condition"
that the select document specifies.
I've added a check for error conditions within handle_expt_event(),
which induces a handle_close() on discovery of an error, handle_ex
Josiah Carlson added the comment:
When push is called in the current trunk (as of 2.6), the data is
automatically chopped up into self.ac_out_buffer_size blocks for later
writing.
In order to force the use of the asynchat.simple_producer class (which
takes an argument for the block size to
Josiah Carlson added the comment:
Your analysis WRT handle_expt_event() is correct. I've been meaning to
fix that for a while, but I forgot to do it in 2.6/3.0 with all of the
other changes/fixes. Looking at the docs, you are also right about
POLLNVAL.
I also don't *know* what
Josiah Carlson added the comment:
I don't believe this should be closed. The functionality is still
desired by me and others who have posted on and off since the patch was
created. This patch definitely needs some love (tests m
Josiah Carlson added the comment:
Well...the loop can also die if an uncaptured exception is raised, but
I'm not sure that is necessary to spell out explicitly.
--
message_count: 2.0 -> 3.0
___
Python tracker
<http://bugs.python.or
Josiah Carlson added the comment:
Actually, that's exactly what it does. If the count is missing, it
defaults to None. The code that is executed is exactly:
if count is None:
while map:
poll_fun(timeout, map)
It will loop until the map is
Josiah Carlson added the comment:
Here's a better patch without tabs.
Added file: http://bugs.python.org/file13238/scheduler_partial.patch
___
Python tracker
<http://bugs.python.org/i
Changes by Josiah Carlson :
Removed file: http://bugs.python.org/file13237/scheduler_partial.patch
___
Python tracker
<http://bugs.python.org/issue1641>
___
___
Python-bug
Josiah Carlson added the comment:
I've just attached a patch to sched.py and asyncore.py to offer a richer
set of features for sched.py, with a call_later() function and minimal
related classes for asyncore.py to handle most reasonable use-cases.
There is no documentation or tests, but
Josiah Carlson added the comment:
Forest:
To answer your question, yes, that blog post discusses a better variant
of sched.py , but no, there isn't a bug. I should probably post it some
time soon for 2.7/3.1 inclusion.
___
Python tracker
Josiah Carlson added the comment:
According to Garth, sockets that don't connect on Windows get put into
the error sockets list.
According to John, you need to poll sockets to determine whether or not
the attempted connection was refused.
If Garth is right, the problem is fixed, thou
Josiah Carlson added the comment:
Considering that we're looking at 2.7 and 3.1, I think that
(paraphrased) "logging fallout from changes to 2.4" are a bit out-of-
date. People who have continued to use asyncore/asynchat in the last 4
years have already changed their code. P
Josiah Carlson added the comment:
Feel like writing some documentation?
___
Python tracker
<http://bugs.python.org/issue5097>
___
___
Python-bugs-list mailing list
Unsub
Josiah Carlson <[EMAIL PROTECTED]> added the comment:
Oy. You are right. Fixed in Py3k in r67286, in trunk (2.7) in r67287,
and 2.6-maintenance in r67288.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PR
Josiah Carlson <[EMAIL PROTECTED]> added the comment:
I agree with Giampaolo. In the case of non-blocking sockets, if reading
from the ssl stream fails because there is no data on the socket, then
sitting in a while loop is just going to busy-wait until data is
discovered.
Never min
Josiah Carlson <[EMAIL PROTECTED]> added the comment:
Zope's medusa was relying on internal details of asyncore (the
ac_out_buffer attribute), which is no longer applicable. It also seems
as though much of medusa itself borrows from asynchat.async_chat, which
suggests that it shou
Josiah Carlson <[EMAIL PROTECTED]> added the comment:
3.0 is a no-go, no non-documentation changes allowed.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Josiah Carlson <[EMAIL PROTECTED]> added the comment:
While handle_expt() is documented has only being called when OOB data is
known, it has become the catch-all for "something strange is happening
on the socket".
The reason it wasn't changed/fixed in Python 2.6 is becaus
Josiah Carlson <[EMAIL PROTECTED]> added the comment:
The patch does not work as Giampaolo intends. If the patch were applied
as-is, no emails longer than 998 bytes could be sent.
Instead, incrementing linelen in the collect_incoming_data() method
should only be performed if self.term
Josiah Carlson <[EMAIL PROTECTED]> added the comment:
Thank you for the report (fixed in the newly attached version) :) .
Added file: http://bugs.python.org/file11602/sq_dict.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Josiah Carlson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11472/sq_dict.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Josiah Carlson <[EMAIL PROTECTED]> added the comment:
Being able to test the async features of both sides of the SSL
connection is a good thing.
Also, the subclass provides a useful example for users who want to use
asyncore and ssl servers without blocking on an incoming conn
Josiah Carlson <[EMAIL PROTECTED]> added the comment:
I have an updated sched.py module which significantly improves the
performance of the cancel() operation on scheduled events (amortized
O(log(n)), as opposed to O(n) as it is currently). This is sufficient
to make sched.py in
Josiah Carlson <[EMAIL PROTECTED]> added the comment:
Fixed documentation in revision 66510. Also, the parameters changed
long before rc2. ;)
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PR
Josiah Carlson <[EMAIL PROTECTED]> added the comment:
Here's a version with views from Python 3.0 for keys, values, and items
:) . I know that no one hear likes my particular implementation (though
it offers more or less the full interface), but the Keys, Values, and
Items cla
1 - 100 of 134 matches
Mail list logo