[issue1509060] Interrupt/kill threads w/exception

Change by Josiah Carlson : -- nosy: -josiahcarlson ___ Python tracker <https://bugs.python.org/issue1509060> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by Josiah Carlson : -- nosy: -josiahcarlson ___ Python tracker <https://bugs.python.org/issue1572968> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1453973] addheaders for urlopen / open / xxxx_open

Change by Josiah Carlson : -- nosy: -josiahcarlson ___ Python tracker <https://bugs.python.org/issue1453973> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue3783] dbm.sqlite proof of concept

Change by Josiah Carlson : -- nosy: -josiahcarlson ___ Python tracker <https://bugs.python.org/issue3783> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by Josiah Carlson : -- nosy: -josiah.carlson, josiahcarlson ___ Python tracker <https://bugs.python.org/issue13451> ___ ___ Python-bugs-list mailin

[issue1043134] Add preferred extensions for MIME types

Change by Josiah Carlson : -- nosy: -josiahcarlson ___ Python tracker <https://bugs.python.org/issue1043134> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35913] asyncore: allow handling of half closed connections

Change by Josiah Carlson : -- nosy: -josiahcarlson ___ Python tracker <https://bugs.python.org/issue35913> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue13372] handle_close called twice in poll2

Change by Josiah Carlson : -- nosy: -josiahcarlson ___ Python tracker <https://bugs.python.org/issue13372> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue6911] Document changes in asynchat

Change by Josiah Carlson : -- nosy: -josiahcarlson ___ Python tracker <https://bugs.python.org/issue6911> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue4277] asynchat's handle_error inconsistency

Change by Josiah Carlson : -- nosy: -josiah.carlson, josiahcarlson ___ Python tracker <https://bugs.python.org/issue4277> ___ ___ Python-bugs-list mailin

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

Change by Josiah Carlson : -- nosy: -josiahcarlson ___ Python tracker <https://bugs.python.org/issue1442493> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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

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

Change by Josiah Carlson : -- nosy: -josiahcarlson ___ Python tracker <https://bugs.python.org/issue1260171> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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

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

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

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

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

ANN: rom 0.29.0 - Redis object mapper for Python

Hey everyone, The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy with the declarative base, or Appengine's datastore. The changelog for recent releases can be seen below my signature. You can find the package at:

[issue1191964] asynchronous Subprocess

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

[issue1191964] asynchronous Subprocess

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

[issue1191964] asynchronous Subprocess

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

[issue1191964] asynchronous Subprocess

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

[issue1191964] asynchronous Subprocess

Josiah Carlson added the comment: Richard: short timeouts are no longer an issue. Nothing to worry about :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1191964

[issue1191964] asynchronous Subprocess

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

[issue1191964] asynchronous Subprocess

Changes by Josiah Carlson josiah.carl...@gmail.com: Added file: http://bugs.python.org/file34861/subprocess_5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1191964

[issue1191964] asynchronous Subprocess

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

[issue1191964] asynchronous Subprocess

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

[issue1191964] asynchronous Subprocess

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 rep...@bugs.python.org http://bugs.python.org/issue1191964

[issue1191964] asynchronous Subprocess

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

[issue1191964] asynchronous Subprocess

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

ANN: rom 0.26.1 - Redis object mapper for Pthon

Hey everyone, The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy with the declarative base, or Appengine's datastore. The changelog for recent releases can be seen below my signature. You can find the package at:

[issue1191964] asynchronous Subprocess

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

[issue1191964] asynchronous Subprocess

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

[issue1191964] asynchronous Subprocess

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

[issue1191964] asynchronous Subprocess

Changes by Josiah Carlson josiah.carl...@gmail.com: -- versions: +Python 3.5 -Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1191964

ANN: rom 0.25.0 - Redis object mapper for Python

Hey everyone, Big change today: rom now supports fast prefix, suffix, and pattern match queries over your data. The method is based on the autocomplete process described in my book, Redis in Action The rom package is a Redis object mapper for Python. It sports an interface similar to Django's

ANN: rom 0.25.0 - Redis object mapper for Python

Hey everyone, Big change today: rom now supports fast prefix, suffix, and pattern match queries over your data. The method is based on the autocomplete process described in my book, Redis in Action The rom package is a Redis object mapper for Python. It sports an interface similar to Django's

ANN: rom 0.22 - Redis object mapper for Python

Hey everyone, As time progresses, so does my Redis object mapper. The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy + Elixir, or Appengine's datastore. The changelog for recent releases can be seen below my signature. You can find

ANN: rom 0.22 - Redis object mapper for Python

Hey everyone, As time progresses, so does my Redis object mapper. The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy + Elixir, or Appengine's datastore. The changelog for recent releases can be seen below my signature. You can find

ANN: RPQueue 0.22

Hello everyone, For those of you who didn't know, if you are interested in a Redis-backed time and/or fifo-queue with priorities, retries, etc., to be used with Python, one exists and is mature: it's called RPQueue, and it seeks to simplify your life of task execution. The recent changelog

ANN: RPQueue 0.22

Hello everyone, For those of you who didn't know, if you are interested in a Redis-backed time and/or fifo-queue with priorities, retries, etc., to be used with Python, one exists and is mature: it's called RPQueue, and it seeks to simplify your life of task execution. The recent changelog

ANN: rom 0.21 - Redis object mapper for Python

Hey everyone, As time progresses, so does my Redis object mapper. The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy + Elixir, or Appengine's datastore. The changelog for recent releases can be seen below my signature. You can find

ANN: rom 0.21 - Redis object mapper for Python

Hey everyone, As time progresses, so does my Redis object mapper. The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy + Elixir, or Appengine's datastore. The changelog for recent releases can be seen below my signature. You can find

ANN: RPQueue 0.21

Hello everyone, For those of you who didn't know, if you are interested in a Redis-backed time and/or fifo-queue with priorities, retries, etc., to be used with Python, one exists and is mature: it's called RPQueue, and it seeks to simplify your life of task execution. The recent changelog

ANN: RPQueue 0.21

Hello everyone, For those of you who didn't know, if you are interested in a Redis-backed time and/or fifo-queue with priorities, retries, etc., to be used with Python, one exists and is mature: it's called RPQueue, and it seeks to simplify your life of task execution. The recent changelog

Ann: rom 0.20 - Redis object mapper for Python

Hey everyone, As time progresses, so does my Redis object mapper. The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy + Elixir, or Appengine's datastore. The changelog for recent releases can be seen below my signature. You can find

Ann: rom 0.20 - Redis object mapper for Python

Hey everyone, As time progresses, so does my Redis object mapper. The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy + Elixir, or Appengine's datastore. The changelog for recent releases can be seen below my signature. You can find

ANN: rom 0.19 - Redis object mapper for Python

Hey everyone, As time progresses, so does my Redis object mapper. The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy + Elixir, or Appengine's datastore. The changelog for recent releases can be seen below my signature. You can find

ANN: rom 0.18 - Redis object mapper for Python

Hey everyone, As time progresses, so does my Redis object mapper. The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy + Elixir, or Appengine's datastore. The changelog for recent releases can be seen below my signature. You can find

ANN: rom 0.18 - Redis object mapper for Python

Hey everyone, As time progresses, so does my Redis object mapper. The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy + Elixir, or Appengine's datastore. The changelog for recent releases can be seen below my signature. You can find

ANN: rom 0.16 - Redis object mapper for Python

Hey everyone, As time progresses, so does my Redis object mapper. The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy + Elixir, or Appengine's datastore. The changelog for recent releases can be seen below my signature. You can find

ANN: rom 0.16 - Redis object mapper for Python

Hey everyone, As time progresses, so does my Redis object mapper. The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy + Elixir, or Appengine's datastore. The changelog for recent releases can be seen below my signature. You can find

ANN: rom 0.10 - Redis object mapper for Python

Hey everyone, I know, it's been several years since I announced anything on these lists, but I suspect that some of you may have uses for my new package, so here you go. The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy + Elixir, or

ANN: rom 0.10 - Redis object mapper for Python

Hey everyone, I know, it's been several years since I announced anything on these lists, but I suspect that some of you may have uses for my new package, so here you go. The rom package is a Redis object mapper for Python. It sports an interface similar to Django's ORM, SQLAlchemy + Elixir, or

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

Josiah Carlson josiahcarl...@users.sourceforge.net 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 rep

[issue8684] improvements to sched.py

New submission from Josiah Carlson josiahcarl...@users.sourceforge.net: 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

[issue1641] asyncore delayed calls feature

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue8543] asynchat documentation issues

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue1023290] proposed struct module format code addition

Josiah Carlson josiahcarl...@users.sourceforge.net 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

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

Josiah Carlson josiahcarl...@users.sourceforge.net 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

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

Josiah Carlson josiahcarl...@users.sourceforge.net 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

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

Changes by Josiah Carlson josiahcarl...@users.sourceforge.net: Removed file: http://bugs.python.org/file14581/asyncore_fix_refused.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6550

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

Changes by Josiah Carlson josiahcarl...@users.sourceforge.net: Removed file: http://bugs.python.org/file14585/asyncore_fix_refused-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6550

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

Josiah Carlson josiahcarl...@users.sourceforge.net 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

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

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue1314572] Trailing slash redirection for SimpleHTTPServer

Josiah Carlson josiahcarl...@users.sourceforge.net added the comment: The other patch is more correct. Closing. -- resolution: - duplicate status: open - closed superseder: - SimpleHTTPServer directory-indexing bug fix ___ Python tracker rep

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue5798] test_asynchat fails on Mac OSX

Changes by Josiah Carlson josiahcarl...@users.sourceforge.net: Removed file: http://bugs.python.org/file13934/asyncore_fix_mac_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5798

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson josiahcarl...@users.sourceforge.net added the comment: Fixed in trunk in 73182, fixed in py3k in 73183. Closing as fixed. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org

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

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue5798] test_asynchat fails on Mac OSX

Changes by Josiah Carlson josiahcarl...@users.sourceforge.net: Removed file: http://bugs.python.org/file13915/asyncore_fix_mac.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5798

[issue5798] test_asynchat fails on Mac OSX

Changes by Josiah Carlson josiahcarl...@users.sourceforge.net: Removed file: http://bugs.python.org/file13918/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5798

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue5798] test_asynchat fails on Mac OSX

Josiah Carlson josiahcarl...@users.sourceforge.net added the comment: As an aside, I was testing against trunk, not 3.1b1 . -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5798

[issue1641] asyncore delayed calls feature

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue1641] asyncore delayed calls feature

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue1641] asyncore delayed calls feature

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue1641] asyncore delayed calls feature

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue1641] asyncore delayed calls feature

Josiah Carlson josiahcarl...@users.sourceforge.net 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

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

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue1161031] Neverending warnings from asyncore

Josiah Carlson josiahcarl...@users.sourceforge.net 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

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

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue1161031] Neverending warnings from asyncore

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue1161031] Neverending warnings from asyncore

Changes by Josiah Carlson josiahcarl...@users.sourceforge.net: Removed file: http://bugs.python.org/file13516/async_no_warn.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1161031

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

Changes by Josiah Carlson josiahcarl...@users.sourceforge.net: -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1370380

[issue1161031] Neverending warnings from asyncore

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue1641] asyncore delayed calls feature

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue1641] asyncore delayed calls feature

Changes by Josiah Carlson josiahcarl...@users.sourceforge.net: Removed file: http://bugs.python.org/file13238/scheduler_partial.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1641

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

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue909005] asyncore fixes and improvements

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue1191964] asynchronous Subprocess

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue5406] asyncore doc issue

Josiah Carlson josiahcarl...@users.sourceforge.net 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

[issue5406] asyncore doc issue

Josiah Carlson josiahcarl...@users.sourceforge.net 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 rep

[issue1641] asyncore delayed calls feature

Josiah Carlson josiahcarl...@users.sourceforge.net 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

  1   2   3   >