[issue1509060] Interrupt/kill threads w/exception

2019-05-01 Thread Josiah Carlson


Change by Josiah Carlson :


--
nosy:  -josiahcarlson

___
Python tracker 
<https://bugs.python.org/issue1509060>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1572968] release GIL while doing I/O operations in the mmap module

2019-05-01 Thread Josiah Carlson


Change by Josiah Carlson :


--
nosy:  -josiahcarlson

___
Python tracker 
<https://bugs.python.org/issue1572968>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1453973] addheaders for urlopen / open / xxxx_open

2019-05-01 Thread Josiah Carlson


Change by Josiah Carlson :


--
nosy:  -josiahcarlson

___
Python tracker 
<https://bugs.python.org/issue1453973>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3783] dbm.sqlite proof of concept

2019-05-01 Thread Josiah Carlson


Change by Josiah Carlson :


--
nosy:  -josiahcarlson

___
Python tracker 
<https://bugs.python.org/issue3783>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue13451] sched.py: speedup cancel() method

2019-05-01 Thread Josiah Carlson


Change by Josiah Carlson :


--
nosy:  -josiah.carlson, josiahcarlson

___
Python tracker 
<https://bugs.python.org/issue13451>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1043134] Add preferred extensions for MIME types

2019-05-01 Thread Josiah Carlson


Change by Josiah Carlson :


--
nosy:  -josiahcarlson

___
Python tracker 
<https://bugs.python.org/issue1043134>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35913] asyncore: allow handling of half closed connections

2019-05-01 Thread Josiah Carlson


Change by Josiah Carlson :


--
nosy:  -josiahcarlson

___
Python tracker 
<https://bugs.python.org/issue35913>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue13372] handle_close called twice in poll2

2019-05-01 Thread Josiah Carlson


Change by Josiah Carlson :


--
nosy:  -josiahcarlson

___
Python tracker 
<https://bugs.python.org/issue13372>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6911] Document changes in asynchat

2019-05-01 Thread Josiah Carlson


Change by Josiah Carlson :


--
nosy:  -josiahcarlson

___
Python tracker 
<https://bugs.python.org/issue6911>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4277] asynchat's handle_error inconsistency

2019-05-01 Thread Josiah Carlson


Change by Josiah Carlson :


--
nosy:  -josiah.carlson, josiahcarlson

___
Python tracker 
<https://bugs.python.org/issue4277>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1442493] IDLE shell window gets very slow when displaying long lines

2019-05-01 Thread Josiah Carlson


Change by Josiah Carlson :


--
nosy:  -josiahcarlson

___
Python tracker 
<https://bugs.python.org/issue1442493>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] add non-blocking read and write methods to subprocess.Popen

2019-05-01 Thread Josiah Carlson


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 
<https://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1260171] subprocess: more general (non-buffering) communication

2019-05-01 Thread Josiah Carlson


Change by Josiah Carlson :


--
nosy:  -josiahcarlson

___
Python tracker 
<https://bugs.python.org/issue1260171>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] add non-blocking read and write methods to subprocess.Popen

2015-03-26 Thread Josiah Carlson

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 non-blocking IO experience.

>From my experience, reading from a socket would always return a string, unless 
>the connection was closed/broken, at which point you got a bad file descriptor 
>exception. Writing would return 0 if the buffer was full, or a bad file 
>descriptor exception if the connection was closed/broken. The implementation 
>of asyncore/asynchat at least until 3.0 shows this in practice, and I doubt 
>this has changed in the intervening years since I updated those libraries for 
>3.0.

My choice to implement this based on BrokenPipeError was based on reading 
Victor(haypo)'s comments from 2014-07-23 and 2014-07-24, in which he stated 
that in asyncio, when it comes to process management, .communicate() hides 
exceptions so that communication can finish, but direct reading and writing 
surface those exceptions.

I was attempting to mimic the asyncio interface simply because it made sense to 
me coming from the socket world, and because asyncio is where people are likely 
to go if the non-blocking subprocess support in subprocess is insufficient for 
their needs.

Note that I also initially resisted raising an exception in those methods, but 
Victor(haypo)'s comments changed my mind.

> Do you know a better method that would allow to distinguish between EOF (no 
> future data, ever) and "would block" (future data possible) without calling 
> process.poll()?

Better is subjective when it comes to API, but different? Yes, it's already 
implemented in patch #8. BrokenPipeError exception when no more data is 
sendable/receivable. A 0 or b'' when writing to a full buffer, or reading from 
an empty buffer. This API tries to be the same as the 
asyncio.subprocess.Process() behavior when accessing stdin, stdout, and stderr 
directly.

> Returning None for non blocking I/O is standard in Python.

In some contexts, yes. In others, no. The asyncio.StreamReader() coroutines 
.read(), .readline(), and .readexactly() return strings. Raw async or sync 
sockets don't return None on read. SSL-wrapped async or sync sockets don't 
return None on read. Asyncio low-level socket operations don't yield None on a 
(currently empty) read.


In the context of the subprocess module as it exists in 3.4 (and 3.5 as it is 
unpatched), the only object that returns None on read when no data is 
available, but where data *might* be available in the future, is an underlying 
posix pipe (on posix platforms) - which isn't generally used directly.

The purpose of this patch is to expose stdin, stdout, and stderr in a way that 
allows non-blocking reads and writes from the subprocess that also plays nicely 
with .communicate() as necessary. Directly exposing the pipes doesn't work due 
to API inconsistencies between Windows and posix, so we have to add a layer.

I would argue that this layer of non-blocking (Windows and posix) pipe 
abstraction has much more in common with how asyncio deals with process IO, or 
how sockets deal with IO, than it does with pipes in general (the vast majority 
of which are blocking), so I would contend that it should have a similar API 
(no returning None).

That said, considering that the expected use of non-blocking subprocess 
communication *does not* include using a multiplexer (select, poll, etc.), I 
have the sense that a few other higher-level methods might be warranted to ease 
use substantially, and which I would expect people would end up using much more 
often than the lower-level direct read/write operations (different names might 
make more sense here):
.write_all(data, timeout=None)
.read_available(bufsize=-1) (and .read_stderr_available)
.read_exactly(bufsize, timeout=None) (and .read_stderr_exactly)

--

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] add non-blocking read and write methods to subprocess.Popen

2015-03-25 Thread Josiah Carlson

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?"

After changing writing to raise BrokenPipeError on a closed pipe, I've also 
changed reading to do the same and added a test to verify the behavior.

--
Added file: http://bugs.python.org/file38691/subprocess_8.patch

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] add non-blocking read and write methods to subprocess.Popen

2015-03-21 Thread Josiah Carlson

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 broken pipe, and 
read/write_nonblocking raising on broken pipe. I'll get a patch in with the 
comments on the existing code review, along with those changes on Monday or 
Tuesday.

--

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-06-02 Thread Josiah Carlson

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 reporting that the process is dead, and we 
tell users to check the results of Popen.poll() in the docs.

Could we bubble up BrokenPipeError? Sure. Does it make sense? In the case of 
Popen.communicate(), exposing the error and changing expected behavior doesn't 
make sense.

I have implemented and would continue to lean towards continuing to hide 
BrokenPipeError on the additional API endpoints. Why? If you know that a 
non-blocking send or receive could result in BrokenPipeError, now you need to 
wrap all of your communication pieces in BrokenPipeError handlers. Does it give 
you more control? Yes. But the majority of consumers of this API (and most APIs 
in general) will experience failure and could lose critical information before 
they realize, "Oh wait, I need to wrap all of these communication pieces in 
exception handlers."

I would be open to adding either a keyword-only argument to the methods and/or 
an instance attribute to enable/disable raising of BrokenPipeErrors during the 
non-blocking calls if others think that this added level of control. I would 
lean towards an instance attribute that is defaulted to False.

--

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-05-29 Thread Josiah Carlson

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.

--
Added file: http://bugs.python.org/file35407/subprocess_7.patch

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-05-19 Thread Josiah Carlson

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 email thread.

--

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-04-17 Thread Josiah Carlson

Josiah Carlson added the comment:

Richard: short timeouts are no longer an issue. Nothing to worry about :)

--

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-04-17 Thread Josiah Carlson

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 Richard Oudkerk's earlier note about ReadFile on overlapped IOs.

I left similar notes next to your comments.

On the method naming side of things, note that you can only write to "stdin", 
and you can only read from "stdout" or "stderr". This is documented behavior, 
so I believe the method names are already quite reasonable (and BDFL approved 
;)).

--
Added file: http://bugs.python.org/file34941/subprocess_6.patch

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-04-14 Thread Josiah Carlson

Changes by Josiah Carlson :


Added file: http://bugs.python.org/file34861/subprocess_5.patch

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-04-14 Thread Josiah Carlson

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 completes are kicked back as a 0 byte write. The 
communicate() method does the right thing with pre-existing non-blocking 
writes, whether input is passed or not.

I also eliminated universal_newline support for non-blocking reads and writes 
to prevent error conditions on edge cases:

On the write side of things, you could end up with a partial multi-byte 
character write, which with universal newlines, would be impossible to finish 
the send using the public API without first modifying state attributes on the 
Popen object (disabling universal newlines for a subsequent bytes 
write_nonblocking() call).

On the read side of things, if you get a partial read of a multi-byte 
character, then the subsequent decode operation would fail with a 
UnicodeDecodeError. Though you could pull the original bytes from the 
exception, that's an awful API to create.

--
Added file: http://bugs.python.org/file34851/subprocess_4.patch

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-04-12 Thread Josiah Carlson

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 explicitly wait for ov.pending to be False, even if you alternate 
between checking for ov.pending to be False and for WaitForSingleObject() to 
return that the event was signaled (which may never actually happen, according 
to my tests), ov.getresult(True) could *still* raise an exception (that same 
WinError 995), and we *still* don't know how much data was sent.

As one of your comments on subprocess_2.patch, you said:
> Should probably add an assertion that 512 bytes was written.

That's not always the case. I found several odd byte writes, and some writes 
that were whatever blocksize I'd chosen minus 32 bytes (though not reported on 
the write side due to the aforementioned exception/counting error, but the 
child process read an odd number of bytes).

How about you take a look at the patch I'm uploading now. It gets rid of the 
loop in write_nonblocking(), as per Giampaolo's request adds a blocksize 
parameter on reading, and because I was in there, I added a timeout to writing.

If in this new patch I'm doing something wrong, and you can explain via code 
how to guarantee that ProcessTestCase._test_multiple_passes doesn't fail, I'd 
really appreciate it.

--
Added file: http://bugs.python.org/file34794/subprocess_3.patch

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-04-11 Thread Josiah Carlson

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 a bit more, this zero result is caused by ov.cancel() followed by 
ov.getresult() raising an OSError, specifically:
[WinError 995] The I/O operation has been aborted because of either a thread 
exit or an application request

That causes us to observe on the Python side of things that zero data was sent 
for some writes, but when looking at what the child process actually received, 
we discover that some data was actually sent. How much compared to what we 
thought we sent? That depends. I observed in testing today that the client 
could receive ~3.5 megs when we thought we had sent ~3 megs.

To make a long story short-ish, using Overlapped IO with WriteFile() and 
Overlapped.cancel(), without pausing between attempts with either a sleep or 
something else results in a difference in what we think vs. reality roughly 87% 
of the time with 512 byte chunks (87 trials out of 100), and roughly 100% of 
the time with 4096 byte chunks (100 trials out of 100). Note that this is when 
constantly trying to write data to the pipe. (each trial is as many 
Popen.write_nonblocking() calls as can complete in .25 seconds)

Inducing a 1 ms sleep between each overlapped.WriteFile() attempt drops the 
error rate to 0/100 trials and 1/100 trials for 512 byte and 4096 byte writes, 
respectively. Testing for larger block sizes suggests that 2048 bytes is the 
largest send that we can push through and actually get correct results.


So, according to my tests, there isn't a method by which we can both cancel an 
overlapped IO while at the same time guaranteeing that we will account exactly 
for the data that was actually sent without adding an implicit or explicit 
delay. Which makes sense as we are basically trying to interrupt another 
process in their attempts to read data that we said they could read, but doing 
so via a kernel call that interrupts another kernel call that is doing 
chunk-by-chunk copies from our write buffer (maybe to some kernel memory then) 
to their read buffer.

Anyway, by cutting down what we attempt to send at any one time, and forcing 
delays between attempted sends, we can come pretty close to guaranteeing that 
child processes don't have any sends that we can't account for. I'll try to get 
a patch out this weekend that encompasses these ideas with a new test that 
demonstrates the issue on Windows (for those who want to verify my results).

--

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-04-09 Thread Josiah Carlson

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/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-04-06 Thread Josiah Carlson

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/file34743/subprocess.patch

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-04-04 Thread Josiah Carlson

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 variant of 
communicate(), as there is no benefit to doing so, and the function is as 
re-entrant as the original.

--

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-04-04 Thread Josiah Carlson

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 uses subprocessing, so I 
needed to defer import of _overlapped until one of a couple crucial methods 
were being called in order to prevent issues relating to circular imports.

I also ended up moving asyncio.windows_utils.pipe out to subprocess, as 
copying/pasting it for a third 'create an overlapped-io pipe' implementation 
for the standard library just doesn't make a lot of sense, and another circular 
import seemed like a bad idea. If/when subprocess goes away completely, someone 
else can move the function back.

With overlapped IOs able to be cancelled, it's not all that bad to make a 
completely re-entrant communicate() without threads, though I made a few 
mistakes in my first pass tonight that I need to fix tomorrow.

--

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-04-02 Thread Josiah Carlson

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 pieces than I do. 
Richard, thank you for the post, I wasn't looking hard enough for how to get 
overlapped IOs to work, and your message made me look harder.

On Linux, it is trivial to support the blocking communicate() and non-blocking 
additions. There's only one weirdness, and that's the fcntl bit flipping during 
write.

On Windows, it's not all that difficult to switch to using overlapped IOs for 
*all* writes, and maybe even for communicate()-based reads, which would remove 
the need for threads. Ironically enough, non-blocking reads actually *don't* 
require overlapped IO thanks to PeekNamedPipe, which could even be used to cut 
the number of extra threads from 2 to 1 in communicate().

Now that I've got it working, I can do one of the following (from least changes 
to the most):
1. Add a "nonblocking" flag, which pre-flips the fcntl bit in Linux and uses 
overlapped IO on writes in Windows - this would be documented to remove the 
ability to call communicate()
2. As an alternative to #1, I can create a new class that lacks the 
communicate() method and adds the non-blocking methods
3. Gut/rewrite the Windows-based communicate() function to use overlapped IO on 
everything, removing the threads, and making it at least superficially like 
Linux (prepare your overlapped IO, then use WaitForMultipleObjects() to 
multiplex), while also adding the non-blocking methods

Unless someone brings up an important counterpoint, I'll work on #3 tonight or 
tomorrow evening to get an initial code/test patch, with docs coming shortly 
after (if not immediately).

--

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-03-29 Thread Josiah Carlson

Changes by Josiah Carlson :


--
versions: +Python 3.5 -Python 3.3, Python 3.4

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2014-03-29 Thread Josiah Carlson

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

His suggested API is:
proc.write_nonblocking(data)
data = proc.read_nonblocking()
data = proc.read_stderr_nonblocking()


I've implemented the API for Windows and Linux, and below are my findings.


On the Linux side of things, everything seems to be working more or less as 
expected, though in writing tests I did need to add an optional argument to 
qcat.py in order to have it flush its stdout to be able to read from the parent 
process. Odd, but whatever.

Also, Richard Oudkerk's claims above about not needing to use fcntl to swap 
flags is not correct. It's necessary to not block on reading, even if select is 
used. Select just guarantees that there is at least 1 byte or a closed handle, 
not that your full read will complete.


On the Windows side of things, my assumptions about WriteFile() were flawed, 
and it seems that the only way to make it actually not block if/when the 
outgoing buffer is full is to create a secondary thread to handle the writing*. 
I've scoured the MSDN docs and there doesn't seem to be an available API for 
interrogating the pipe to determine whether the buffer is full, how full it is, 
or whether the write that you'd like to do will succeed or block.

* This applies even with the use of asyncio. Because the intent for the call is 
to return more or less immediately, a thread still has to be created to handle 
the event loop for IO completion, which means that asyncio can't prevent the 
use of threads and not block without basically integrating an event loop into 
the caller.

Considering that the Windows communicate() method already uses threads to 
handle reading and writing, I don't believe it is a big deal to add it for this 
situation too. Any major objections?

--

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue11265] asyncore does not check for EAGAIN and EPIPE errno

2011-03-01 Thread Josiah Carlson

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/issue11265>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1641] asyncore delayed calls feature

2010-05-10 Thread Josiah Carlson

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 tracker 
<http://bugs.python.org/issue1641>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8684] improvements to sched.py

2010-05-10 Thread Josiah Carlson

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 a bit easier.

--
assignee: giampaolo.rodola
components: Library (Lib)
files: sched.patch
keywords: needs review, patch, patch
messages: 105483
nosy: giampaolo.rodola, josiahcarlson
priority: low
severity: normal
status: open
title: improvements to sched.py
type: feature request
Added file: http://bugs.python.org/file17289/sched.patch

___
Python tracker 
<http://bugs.python.org/issue8684>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8543] asynchat documentation issues

2010-04-27 Thread Josiah Carlson

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.

--

___
Python tracker 
<http://bugs.python.org/issue8543>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1023290] proposed struct module format code addition

2009-08-15 Thread Josiah Carlson

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 makes sense to backport this to trunk so we 
get this in 2.7?  I personally would like to see it there, and would 
even be ok with a limitation that it only exists as part of longs.  If 
someone has the time to backport it; cool.  If not, I understand, and 
could live with it only being in 3.x .

Thank you for taking the time and making the effort in getting this into 
a recent Python :)

--

___
Python tracker 
<http://bugs.python.org/issue1023290>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6550] asyncore incorrect failure when connection is refused and using async_chat channel

2009-08-01 Thread Josiah Carlson

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 mine (Monday, likely), 
I'll comment then.

In terms of "handle_expt_event should handle the low level expt event 
called from select", what you don't seem understand is that and "expt 
event" is not an exception event, it's a "we got OOB data" event, and 
with the patches, it is called at *exactly* the time it should be: when 
there is OOB data.  It used to be mistakenly called in the select loop 
whenever any sort of non-normal condition happened on the socket, which 
was a serious design flaw, and lead to significant misunderstanding 
about the purpose of the method.

With the _exception() call as-is, it now behaves like the 
asyncore.poll2() function, which is the right thing.

--

___
Python tracker 
<http://bugs.python.org/issue6550>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6550] asyncore incorrect failure when connection is refused and using async_chat channel

2009-07-29 Thread Josiah Carlson

Changes by Josiah Carlson :


Removed file: http://bugs.python.org/file14585/asyncore_fix_refused-2.patch

___
Python tracker 
<http://bugs.python.org/issue6550>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6550] asyncore incorrect failure when connection is refused and using async_chat channel

2009-07-29 Thread Josiah Carlson

Changes by Josiah Carlson :


Removed file: http://bugs.python.org/file14581/asyncore_fix_refused.patch

___
Python tracker 
<http://bugs.python.org/issue6550>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6550] asyncore incorrect failure when connection is refused and using async_chat channel

2009-07-29 Thread Josiah Carlson

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 thing WRT handle_expt_event(), which it 
makes sense to apply to the standard select-based asyncore.poll().  
That's what this does (in addition to fixing the close case that you 
pointed out).

In terms of "only implementing low-level stuff", this is still the case.  
You still only need to implement handle_*(), not handle_*_event() .  But 
now, handle_expt_event() isn't written to do more than it should have 
been doing in the first place.

I've updated the patch to include semantics for actually handling OOB 
data, which I've verified by using a slightly modified pyftpdlib (remove 
the socket option calls to set socket.SO_OOBINLINE) and it's tests on 
both Windows and Ubuntu 8.04 (I also ran the full Python test suite on 
my Ubuntu install, and any failures were obviously not asyncore/asynchat 
related).

--
Added file: http://bugs.python.org/file14596/asyncore_fix_refused-3.patch

___
Python tracker 
<http://bugs.python.org/issue6550>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6550] asyncore incorrect failure when connection is refused and using async_chat channel

2009-07-28 Thread Josiah Carlson

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 this.  I forgot to fix it earlier, which is why it's 
making it into this patch.

Secondly, I pulled the part that was inside handle_expt_event() that was 
being used to find the exception and pulls it out into _exception(), 
removing the previous behavior (wrt to the broken API), and replacing it 
with something that is cleaner and more correct (assuming sockets).

To respond to it being an issue that the object has a socket with a 
getsockopt(), I can fix it to handle the AttributeError case.

Would you be willing to try this out given my explanation as to why I 
changed your patch?

--
Added file: http://bugs.python.org/file14585/asyncore_fix_refused-2.patch

___
Python tracker 
<http://bugs.python.org/issue6550>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6550] asyncore incorrect failure when connection is refused and using async_chat channel

2009-07-27 Thread Josiah Carlson

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?

--
assignee:  -> josiahcarlson
keywords: +needs review
Added file: http://bugs.python.org/file14581/asyncore_fix_refused.patch

___
Python tracker 
<http://bugs.python.org/issue6550>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1314572] Trailing slash redirection for SimpleHTTPServer

2009-07-01 Thread Josiah Carlson

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.python.org/issue1314572>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-06-04 Thread Josiah Carlson

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.

Looking at line 106 in py3k/Lib/asyncore.py 
(http://svn.python.org/view/python/branches/py3k/Lib/asyncore.py?
annotate=73183) gets me "obj.handle_close()".  Your tracebacks show line 
106 calling "obj.handle_expt_event()", which is the old code.

--

___
Python tracker 
<http://bugs.python.org/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-06-03 Thread Josiah Carlson

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/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-06-03 Thread Josiah Carlson

Changes by Josiah Carlson :


Removed file: http://bugs.python.org/file13934/asyncore_fix_mac_2.patch

___
Python tracker 
<http://bugs.python.org/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-06-03 Thread Josiah Carlson

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 work for 
them).

--

___
Python tracker 
<http://bugs.python.org/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1563] asyncore and asynchat incompatible with Py3k str and bytes

2009-05-29 Thread Josiah Carlson

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 implicit with the fact that we are 
reading/writing to sockets.

--

___
Python tracker 
<http://bugs.python.org/issue1563>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-05-08 Thread Josiah Carlson

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 & select.POLLOUT:
obj.handle_write_event()
if flags & select.POLLPRI:
obj.handle_expt_event()
if flags & (select.POLLHUP | select.POLLERR | select.POLLNVAL):
obj.handle_close()
except socket.error, e:
if e.args[0] not in (EBADF, ECONNRESET, ENOTCONN, ESHUTDOWN, 
ECONNABORTED):
obj.handle_error()
else:
obj.handle_close()
except _reraised_exceptions:
raise
except:
obj.handle_error()

It works on OS X and should work just as well on other platforms.

--

___
Python tracker 
<http://bugs.python.org/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-05-08 Thread Josiah Carlson

Changes by Josiah Carlson :


Removed file: http://bugs.python.org/file13918/unnamed

___
Python tracker 
<http://bugs.python.org/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-05-08 Thread Josiah Carlson

Changes by Josiah Carlson :


Removed file: http://bugs.python.org/file13915/asyncore_fix_mac.patch

___
Python tracker 
<http://bugs.python.org/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-05-08 Thread Josiah Carlson

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 while it's waiting for the connection.

Options:
If we swap the pollin/pollout conditions, that would fix the hang on 
mac, but cause the hang on others (I'm not really worried about not 
doing a write after a read, .push() in asynchat performs an immediate 
send).

If we get rid of the .connected check, then when a .read() fails and 
causes a close, then we get an exception in handle_write().

If we swap to Giampaolo's variant, then we could lose data that was 
legitimately sent by a client.

I've got a version that doesn't hang on OS X, and should work on all 
platforms.  It's ugly, but it works.

--
Added file: http://bugs.python.org/file13934/asyncore_fix_mac_2.patch

___
Python tracker 
<http://bugs.python.org/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-05-08 Thread Josiah Carlson

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's .close_when_done() method.

If you get a read signal, generally you want to try to pull more data 
before you close, because when you close, you can never get any pending 
data again.

For example, if I were to use:
  chat.send("commit\n")
  chat.close_when_done()
It's very likely that on even moderate latency network connections 
(10ms), the other end would get the close signal at the same time as the 
read for the "commit\n" message.  But since they close before they read, 
they never get the "commit" message, and maybe a transaction is 
reverted.

My primary concern is keeping the library correct.  Adding attributes in 
the test cases don't bother me.

Jean: on what platform are you experiencing the hang?  Are you using 
trunk or 3.1?

--

___
Python tracker 
<http://bugs.python.org/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-05-07 Thread Josiah Carlson

Josiah Carlson  added the comment:

As an aside, I was testing against trunk, not 3.1b1 .

--

___
Python tracker 
<http://bugs.python.org/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-05-07 Thread Josiah Carlson

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 
.connected attribute, which the test objects lack.

The attached patch fixes the test on my OS X machine, which you should 
test.

--
keywords: +patch
Added file: http://bugs.python.org/file13915/asyncore_fix_mac.patch

___
Python tracker 
<http://bugs.python.org/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-05-07 Thread Josiah Carlson

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/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-05-07 Thread Josiah Carlson

Josiah Carlson  added the comment:

Try getting rid of the "and" clause in the select.POLLIN .

--

___
Python tracker 
<http://bugs.python.org/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-05-07 Thread Josiah Carlson

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.POLLPRI and obj.connected:
obj.handle_expt_event()
if flags & (select.POLLHUP | select.POLLERR | select.POLLNVAL):
obj.handle_close()

--

___
Python tracker 
<http://bugs.python.org/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-05-07 Thread Josiah Carlson

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.python.org/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5798] test_asynchat fails on Mac OSX

2009-05-07 Thread Josiah Carlson

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.

--

___
Python tracker 
<http://bugs.python.org/issue5798>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1641] asyncore delayed calls feature

2009-04-02 Thread Josiah Carlson

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 use of the code 
you must subclass async_chat, providing meaningful 
collect_incoming_data() and found_terminator() methods. The 
asyncore.dispatcher methods can be used, although not all make sense in 
a message/response context."

How can we make the documentation better?  I'm too close to the 
documentation to really know how to improve it.  Ideas?

--

___
Python tracker 
<http://bugs.python.org/issue1641>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5661] asyncore should catch EPIPE while sending() and receiving()

2009-04-01 Thread Josiah Carlson

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 if/when new failure conditions arise.

--
assignee:  -> josiahcarlson

___
Python tracker 
<http://bugs.python.org/issue5661>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1641] asyncore delayed calls feature

2009-04-01 Thread Josiah Carlson

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 was 
changed.

People who subclassed from asyncore should have no problems.  People who 
subclassed 
from asynchat may have problems.

If we want to revert selected changes to asynchat, that's fine with me.  
AFAICT, there 
is only 1 substantial bugfix in asynchat (if your text terminator isn't 
discovered in 
the first ac_in_buffer_size bytes read since the last terminator, your 
connection will 
hang), which is easily pulled out.  Offering a compatibility mode is also 
relatively 
easy.

Six months ago you were 'eh' with what was going on with the asyncore libraries 
(see 
messages from early October).  Over a year ago everyone on python-dev cared so 
little 
about the libraries that it was preferred to give me commit access than for 
someone to 
review the code.  Now everyone seems willing and happy to remove the library 
because it 
is "unsalvageable".

Ultimately the change that broke Zope/medusa was replacing the use of 
asynchat.fifo 
with a deque, and getting rid of ac_out_buffer.  Those are *tiny* changes that 
we can 
change back, temporarily pull into Zope, and tweak Medusa to fix (I'd be happy 
to offer 
a patch to AMK to produce Medusa 0.5.5).

As for your "subclassing is bad" comment, Twisted, wxPython, SocketServer 
(SimpleXMLRPCServer, TCPServer, ...), sgmllib.SGMLParser, etc., all use 
subclassing as 
part of their APIs.

--

___
Python tracker 
<http://bugs.python.org/issue1641>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1641] asyncore delayed calls feature

2009-04-01 Thread Josiah Carlson

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 that the 
documentation for asyncore is lacking, I agree that I probably wasn't as 
vocal as I could have been prior to the changes, I agree that 3rd 
parties relying on internal implementation details not covered in the 
limited documentation is a problem, I agree that we need to figure 
something out for asyncore 2.7 and beyond, I agree that we need to 
figure something out for asyncore 2.6 issues related to Zope and Medusa, 
...

I'm happy to take the blame for changing asyncore internals in Python 
2.6 .  And I've not stated otherwise in any forum.  At the time I 
thought it was the right thing to do.  If I could change the code 
retroactively, I would probably do so.

But it seems to me that "fork asyncore", "pull asyncore out of the 
stdlib", and "revert to 2.5" are all variants of the cliche "throwing 
the baby out with the bathwater".  There are good bug fixes in 2.6, and 
depending on how much of the internals that Zope and/or medusa rely on, 
we might even be able to write a short wrapper/adapter to throw in to 
Zope and/or asyncore.

I'll contact Tres and Jim, and hopefully be able to come to some 
reasonable solution.

--

___
Python tracker 
<http://bugs.python.org/issue1641>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1641] asyncore delayed calls feature

2009-04-01 Thread Josiah Carlson

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 asyncore so that they can have a say, I'd 
be happy to talk to them.

Generally, what you are saying is that I'm damned if I do, damned if I 
don't.  By taking ownership and attempting to fix and improve the module 
for 2.6 (because there were a bunch of outstanding issues), people are 
pissed (generally those who use Zope and/or medusa).  Despite this, 
other people have continued to use it, and have been pushing for new 
features; event scheduling being one of the major parts.

Pulling asyncore out of Python is silly.  Not improving the module 
because of fear of breakage is silly.  I'm happy to hear suggestions 
from the Zope crew, but I'm only going to put as much effort in 
communicating with them as they do me.

--

___
Python tracker 
<http://bugs.python.org/issue1641>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1641] asyncore delayed calls feature

2009-04-01 Thread Josiah Carlson

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 committed to 2.6 and 3.0 
were committed 3 months prior to 2.6 release, after having languished 
for over a year because no one would review them.  If people care about 
where asyncore/asynchat are going, then it is *their* responsibility to 
at least make an effort in paying attention at least once every few 
months or so.

The delayed calls feature discussed in the current bug doesn't alter the 
behavior of previously existing code, except there are additional checks 
for pending tasks to be executed.  If people never use the call_later() 
API, it is unlikely they will experience any difference in behavior.

If you are concerned about the sched module, I'd be happy to do a search 
for it's use to verify that people aren't relying on it's internal 
implementation, only the features of it's external API.

--

___
Python tracker 
<http://bugs.python.org/issue1641>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue909005] asyncore fixes and improvements

2009-03-31 Thread Josiah Carlson

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 the sake of suppressing the warnings should no longer 
be necessary.

While I can see that it would be *convenient* if close() was 
automatically called, the method is called "handle_close()", and there 
is an expectation about the implementation thereof.  For example, you 
call socket.recv() in handle_read(), you call socket.send() in 
handle_write(), call socket.accept() in handle_accept().  Is it too much 
to expect that a user will call .close() inside handle_close()?

The answer to that last question is a "no", btw.

--

___
Python tracker 
<http://bugs.python.org/issue909005>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2073] asynchat push always sends 512 bytes (ignoring ac_out_buffer_size)

2009-03-31 Thread Josiah Carlson

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 to believe that a larger size 
would tend to perform better, but my concern is sending blocks too large 
to the OS and having it say "sorry, but you need to chop it up more" via 
sock.send() returning 1 or 2 (I've experienced this on Windows with 
stdio and sockets).

Considering how easy it is to adjust, and considering that the value is 
respected everywhere that matters (performance-conscious users aren't 
using simple_producer, nor are they using dispatcher_with_send), I think 
that 4096 is sufficient for the time being.  Adjusting it up to 16k in 
Python 2.8/3.2 seems reasonable to me.  Someone ping me in a year ;) .

--

___
Python tracker 
<http://bugs.python.org/issue2073>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1161031] Neverending warnings from asyncore

2009-03-31 Thread Josiah Carlson

Josiah Carlson  added the comment:

Good point Giampaolo.  Fixed and committed.

--

___
Python tracker 
<http://bugs.python.org/issue1161031>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1641] asyncore delayed calls feature

2009-03-31 Thread Josiah Carlson

Changes by Josiah Carlson :


Removed file: http://bugs.python.org/file13238/scheduler_partial.patch

___
Python tracker 
<http://bugs.python.org/issue1641>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1641] asyncore delayed calls feature

2009-03-31 Thread Josiah Carlson

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 modified sched.py, and doesn't have a 
standard "execute outstanding methods" function built into asyncore 
(asynchat.scheduled_tasks.run(time.time()) is sufficient).

The major difference is that the modifications to sched.py offer a fast 
cancel/reschedule operation, which Giampaolo's lacks.

--
Added file: http://bugs.python.org/file13524/scheduler.patch

___
Python tracker 
<http://bugs.python.org/issue1641>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1161031] Neverending warnings from asyncore

2009-03-31 Thread Josiah Carlson

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 -> closed

___
Python tracker 
<http://bugs.python.org/issue1161031>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1370380] async_chat.push() can trigger handle_error(). undocumented.

2009-03-31 Thread Josiah Carlson

Changes by Josiah Carlson :


--
resolution:  -> wont fix
status: open -> closed

___
Python tracker 
<http://bugs.python.org/issue1370380>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1161031] Neverending warnings from asyncore

2009-03-31 Thread Josiah Carlson

Changes by Josiah Carlson :


Removed file: http://bugs.python.org/file13516/async_no_warn.patch

___
Python tracker 
<http://bugs.python.org/issue1161031>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1161031] Neverending warnings from asyncore

2009-03-31 Thread Josiah Carlson

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_expt() 
otherwise.

One thing to consider is that when there is OOB data, and when 
handle_expt() isn't overridden, we will get churn because that data will 
never be read from the socket.  I'm thinking about tossing a 
handle_close() as part of the default handle_expt() call.

Attached is an updated patch without the handle_close() in 
handle_expt().

--
Added file: http://bugs.python.org/file13517/async_no_warn.patch

___
Python tracker 
<http://bugs.python.org/issue1161031>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2073] asynchat push always sends 512 bytes (ignoring ac_out_buffer_size)

2009-03-31 Thread Josiah Carlson

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 send), you must pass the 
producer itself with push_with_producer() .

Closing as out of date.

--
resolution:  -> out of date
status: open -> closed

___
Python tracker 
<http://bugs.python.org/issue2073>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1161031] Neverending warnings from asyncore

2009-03-31 Thread Josiah Carlson

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 to do when presented with POLLERR, but few 
socket errors are transient (transient errors should be handled by the 
underlying stacks), so I agree with you that they should just be closed.

I went ahead and made the changes as you have suggested, and also made 
the same change with the select-based loop.  Errors on the socket just 
result in closing the socket, resulting in _exception() -> close().

Thinking about it, I've also had a change of heart, and added a 
frozenset object called 'ignore_log_types', which specifies the log 
types to ignore.  By default it is populated with 'warning', which 
squelches all currently existing "unhandled * event" bits.  If you use 
self.log(arg) or self.log_info(one_arg), those lines are unchanged.  
Handle_error() uses the "error" type, which is also nice, but which you 
can also suppress with ease (though you really should be logging them so 
you can fix your code).

I've attached a version that I think is pretty reasonable.  Comments?  
Questions?

--
keywords: +needs review, patch
versions: +Python 2.7 -Python 2.6
Added file: http://bugs.python.org/file13516/async_no_warn.patch

___
Python tracker 
<http://bugs.python.org/issue1161031>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1191964] asynchronous Subprocess

2009-03-30 Thread Josiah Carlson

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 mostly).

--

___
Python tracker 
<http://bugs.python.org/issue1191964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5406] asyncore doc issue

2009-03-09 Thread Josiah Carlson

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.org/issue5406>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5406] asyncore doc issue

2009-03-09 Thread Josiah Carlson

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 empty.

--
message_count: 1.0 -> 2.0

___
Python tracker 
<http://bugs.python.org/issue5406>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1641] asyncore delayed calls feature

2009-03-03 Thread Josiah Carlson

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/issue1641>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com




[issue1641] asyncore delayed calls feature

2009-03-03 Thread Josiah Carlson

Changes by Josiah Carlson :


Removed file: http://bugs.python.org/file13237/scheduler_partial.patch

___
Python tracker 
<http://bugs.python.org/issue1641>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1641] asyncore delayed calls feature

2009-03-03 Thread Josiah Carlson

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 I can add those based on 
Giampaolo's tests and docs if we like this approach better.

Added file: http://bugs.python.org/file13237/scheduler_partial.patch

___
Python tracker 
<http://bugs.python.org/issue1641>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1641] asyncore delayed calls feature

2009-03-03 Thread Josiah Carlson

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 
<http://bugs.python.org/issue1641>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue777588] asyncore is broken for windows if connection is refused

2009-02-13 Thread Josiah Carlson

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, though we aren't quite 
retrieving the correct error code on win32.  If John is right, we need 
to repeatedly check for error conditions on sockets that are trying to 
connect to a remote host, and the problem is not fixed.

___
Python tracker 
<http://bugs.python.org/issue777588>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1161031] Neverending warnings from asyncore

2009-02-11 Thread Josiah Carlson

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.  People who write new code 
already deal with the logging.

Does anyone have a compelling reason as to why we shouldn't just close 
this bug?

___
Python tracker 
<http://bugs.python.org/issue1161031>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5097] asyncore.dispatcher_with_send undocumented

2009-01-30 Thread Josiah Carlson

Josiah Carlson  added the comment:

Feel like writing some documentation?

___
Python tracker 
<http://bugs.python.org/issue5097>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4332] asyncore.file_dispatcher does not use dup()'ed fd

2008-11-19 Thread Josiah Carlson

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 PROTECTED]>
<http://bugs.python.org/issue4332>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

2008-10-21 Thread Josiah Carlson

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 mind that the reference to "sendall" should be replaced by recv.

Whether to 'continue' or 'raise' should be determined by whether the 
socket is blocking.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3890>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4078] asyncore fixes are not backwards compatible

2008-10-08 Thread Josiah Carlson

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 should subclass there.

--
resolution:  -> wont fix

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4078>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1541] Bad OOB data management when using asyncore with select.poll()

2008-10-02 Thread Josiah Carlson

Josiah Carlson <[EMAIL PROTECTED]> added the comment:

3.0 is a no-go, no non-documentation changes allowed.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1541>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1541] Bad OOB data management when using asyncore with select.poll()

2008-10-02 Thread Josiah Carlson

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 because a new method 
would need to be added, which would break previously existing asyncore-
derived applications.

I might still be able to fix it for 3.0 .

--
assignee: akuchling -> josiahcarlson
nosy: +josiahcarlson

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1541>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1745035] DoS smtpd vulnerability

2008-09-29 Thread Josiah Carlson

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.terminator == '\r\n'.

I can apply a modified version of this patch against trunk after 2.6 is 
released.  Backports to 2.5 and 2.6 should then be discussed.

--
assignee: barry -> josiahcarlson
nosy: +josiahcarlson

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1745035>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3783] dbm.sqlite proof of concept

2008-09-25 Thread Josiah Carlson

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.python.org/issue3783>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3783] dbm.sqlite proof of concept

2008-09-25 Thread Josiah Carlson

Changes by Josiah Carlson <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11472/sq_dict.py

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3783>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3899] test_ssl.py doesn't properly test ssl integration with asyncore

2008-09-18 Thread Josiah Carlson

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 connection.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3899>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1641] asyncore delayed calls feature

2008-09-18 Thread Josiah Carlson

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 into the equivalent of a pair heap.

>From there, it's all a matter of desired API and features.

My opinion on the matter: it would be very nice to have the asyncore 
loop handle all of the scheduled events internally.  However, being able 
to schedule and reschedule events is a generally useful feature, and 
inserting the complete functionality into asyncore would unnecessarily 
hide the feature and make it less likely to be used by the Python 
community.

In asyncore, I believe that it would be sufficient to offer the ability 
to call a function within asyncore.loop() before the asyncore.poll() 
call, whose result (if it is a number greater than zero, but less than 
the normal timeout) is the timeout passed to asyncore.poll().  Obviously  
the function scheduler would be written with this asyncore API in mind.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1641>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3904] asynchat async_chat __init__() arguments changed in python 2.6

2008-09-18 Thread Josiah Carlson

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 PROTECTED]>
<http://bugs.python.org/issue3904>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3783] dbm.sqlite proof of concept

2008-09-11 Thread Josiah Carlson

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 classes in the following version are quite generic (they only 
require that the base class implement __iter__, _itervalues, and 
_iteritems), and reasonably optimized.  They could probably be moved 
into the generic dbm stuff and used by everyone.

Added file: http://bugs.python.org/file11472/sq_dict.py

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3783>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



  1   2   >