Re: [Python-Dev] Adding __format__ to classic classes
Guido van Rossum wrote:
> Try this:
>
> if (PyInstance_Check(obj)) {
> bound_method = PyObject_GetAttr(obj, str__format__);
> if (!bound_method)
> return NULL;
>
> Py_DECREF(bound_method);
> return
> }
> else {
> do it the py3k way;
> }
Yes! I had converged on something similar. Also, in the !bound_method
branch, I convert using str() or unicode() to get the same behavior as
object.__format__.
I have one more question, which I'll start in another thread.
Eric.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Calling a builtin from C code; PEP 3101 format() builtin
While implementing "".format(), I need to call the builtin format() function, which I've already implemented (in bltinmodule.c:builtin_format()). In the py3k branch, I just hardcoded the same functionality into "".format(), which seems like the wrong thing to do, given how complex the code is. I see 2 approaches: 1: exposing builtin_format(), probably giving it another name (PyObject_Format?) and moving it somewhere other than bltinmodule.c. 2: Instead of calling the C code directly, lookup "format" in Python's builtins, and call it. This, I think, would allow you to override the global format() function if you wanted to modify the behavior (although I can't think of any use case for wanting to do that). I don't see where either behavior is specified in the PEP. If option 2 is preferred, could someone give me a pointer to how to find a builtin function from C code? Thanks. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Calling a builtin from C code; PEP 3101 format() builtin
Eric Smith schrieb: > While implementing "".format(), I need to call the builtin format() > function, which I've already implemented (in > bltinmodule.c:builtin_format()). In the py3k branch, I just hardcoded > the same functionality into "".format(), which seems like the wrong > thing to do, given how complex the code is. > > I see 2 approaches: > > 1: exposing builtin_format(), probably giving it another name > (PyObject_Format?) and moving it somewhere other than bltinmodule.c. > > 2: Instead of calling the C code directly, lookup "format" in Python's > builtins, and call it. This, I think, would allow you to override the > global format() function if you wanted to modify the behavior (although > I can't think of any use case for wanting to do that). > > I don't see where either behavior is specified in the PEP. > > If option 2 is preferred, could someone give me a pointer to how to find > a builtin function from C code? I don't know which option Guido prefers, but for looking up a function from the builtins, look at Python/import.c:PyImport_Import which does this with __import__. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Calling a builtin from C code; PEP 3101 format() builtin
Eric Smith wrote: > I see 2 approaches: > > 1: exposing builtin_format(), probably giving it another name > (PyObject_Format?) and moving it somewhere other than bltinmodule.c. > > 2: Instead of calling the C code directly, lookup "format" in Python's > builtins, and call it. This, I think, would allow you to override the > global format() function if you wanted to modify the behavior (although > I can't think of any use case for wanting to do that). > > I don't see where either behavior is specified in the PEP. abstract.h/abstract.c is where most of the PyObject_* functions live, so that would be a likely location if we do go with option 1. Given that the formatting PEP goes to great lengths to describe how to make your own custom formatters, I'd be inclined to favour option 1 myself. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
asyncore and asynchat are in a difficult position right now since a lot of patches for both modules are pending and no decisions are taken. In detail I'm talking about patches 1519, 1541, 2073 and 1736190 which is the most important one since it includes a lot of fixes for other reported issues (e.g. 1740572, 1736101, 909005). As I said in 1563, IMHO your patch could be reviewed and eventually committed only after 1736190 and others are committed and 2.x related problems are solved. Converting the code to 3.0 should be the last step also because my perception is that your patch changes too much of the existing code: a new iterator_producer, a different collect_incoming_data() behavior, name mangling of internal variables and others. ...A lot of stuff which could be included in a second time. I'm going to inform Josiah Carlson about this topic since he should be the most experienced one about asyncore and asynchat. On 14 Feb, 03:52, Bill Janssen <[EMAIL PROTECTED]> wrote: > It's a big patch, but I'll try applying it to the current py3k branch > -- does it apply? -- and try a few things with it. I'm concerned > about how well it behaves with things like Medusa (which probably > needs its own py3k update). > > Bill > ___ > Python-Dev mailing list > [EMAIL PROTECTED]://mail.python.org/mailman/listinfo/python-dev > Unsubscribe:http://mail.python.org/mailman/options/python-dev/python-dev2-garchiv... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
(wrong quoting: obvioulsly I was talking to Daniel) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5.2 freeze upcoming
Since I can't change issue assignment I reply here. Issue 1745035 (which is still open) should concern 2.5.2. On 13 Feb, 20:57, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > The 2.5 maintenance branch will be frozen tomorrow (Thursday) > around 7:00 UTC. Please don't make any changes to the branch > after that point unless you are directly involved in the release > process. > > If there are any issues that you think should be considered > before the 2.5.2 release, please assign them to me with high > priority. > > Regards, > Martin > ___ > Python-Dev mailing list > [EMAIL PROTECTED]://mail.python.org/mailman/listinfo/python-dev > Unsubscribe:http://mail.python.org/mailman/options/python-dev/python-dev2-garchiv... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5.2 freeze upcoming
On Feb 13, 2008, at 2:57 PM, Martin v. Löwis wrote: > The 2.5 maintenance branch will be frozen tomorrow (Thursday) > around 7:00 UTC. Please don't make any changes to the branch > after that point unless you are directly involved in the release > process. The documentation packages have been uploaded to python.org. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
2008/2/14, Giampaolo Rodola' <[EMAIL PROTECTED]>: > asyncore and asynchat are in a difficult position right now since a > lot of patches for both modules are pending and no decisions are > taken. > In detail I'm talking about patches 1519, 1541, 2073 and 1736190 which > is the most important one since it includes a lot of fixes for other > reported issues (e.g. 1740572, 1736101, 909005). I took a look to some of these in other opportunity, and IIRC, the main issue here is exactly what you say: lots of issues with problem *and* fixes, but some decisions needs to be taken. No decision taken, the pile of issues (and real problems behind them) accumulate through time. I think it's a good idea to bring this discussion here, and with luck a result will come up regarding them. So, it would be great if you (please) summarize here the problems behind those issues and the decisions that must be taken... Thanks! Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
Ok, I'll try to take a look at all asyncore/chat reports and try to summarize them by splitting patches which solve bugs and patches which add enhancements or functionalities. On 14 Feb, 16:12, "Facundo Batista" <[EMAIL PROTECTED]> wrote: > 2008/2/14, Giampaolo Rodola' <[EMAIL PROTECTED]>: > > > asyncore and asynchat are in a difficult position right now since a > > lot of patches for both modules are pending and no decisions are > > taken. > > In detail I'm talking about patches 1519, 1541, 2073 and 1736190 which > > is the most important one since it includes a lot of fixes for other > > reported issues (e.g. 1740572, 1736101, 909005). > > I took a look to some of these in other opportunity, and IIRC, the > main issue here is exactly what you say: lots of issues with problem > *and* fixes, but some decisions needs to be taken. > > No decision taken, the pile of issues (and real problems behind them) > accumulate through time. I think it's a good idea to bring this > discussion here, and with luck a result will come up regarding them. > > So, it would be great if you (please) summarize here the problems > behind those issues and the decisions that must be taken... Thanks! > > Regards, > > -- > . Facundo > > Blog:http://www.taniquetil.com.ar/plog/ > PyAr:http://www.python.org/ar/ > ___ > Python-Dev mailing list > [EMAIL PROTECTED]://mail.python.org/mailman/listinfo/python-dev > Unsubscribe:http://mail.python.org/mailman/options/python-dev/python-dev2-garchiv... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
First of all, you're conflating my two possible patches. One patch just addresses the problem of strings and bytes, as GvR asked me to do, and adds an 8-line class called iterator_producer that adapts iterators into producers. The patch doesn't change how the module works at all, and iterator_producer is not invoked anywhere within the code; it's purely for user convenience. I consider this the primary patch and would like to focus attention there if possible. The other patch combines the string and bytes fix with a porting of 1736190 and the other things you complain about, most of which scratch personal itches. If the patches you mention are actually going to be applied, then this patch isn't the way to go, and I'll maybe submit parts of it as separate patches. If they're just going to waste away in the bug tracker, though, this patch should be seriously considered. I'm quite willing to re-construct my string and bytes patch against a version of py3k in which the pre-existing patches are already applied. There needs to be forward progress, though: If nothing at all gets done, asyncore is going to be removed from the standard lib. I don't want to see that happen. On Thu, Feb 14, 2008 at 5:55 AM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > (wrong quoting: obvioulsly I was talking to Daniel) > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/djarb%40highenergymagic.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_decimal failure on OSX 10.3
Hi, I've just filed issue2114 (http://bugs.python.org/issue2114) because test_decimal.py fails on OSX 10.3 with Python 2.5.2c1 (using the python.org build that will be released soon). The same test passes on OSX 10.4 and 10.5 (both Intel and PPC) using the exact same binaries. IIRC the 2.5.1 release had no unexpected test failures on OSX 10.3, so this is a regression in that regard. Ronald ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_decimal failure on OSX 10.3
On 14 Feb, 2008, at 17:48, Mark Dickinson wrote: On Thu, Feb 14, 2008 at 11:21 AM, Ronald Oussoren <[EMAIL PROTECTED] > wrote: Hi, I've just filed issue2114 (http://bugs.python.org/issue2114) because test_decimal.py fails on OSX 10.3 with Python 2.5.2c1. It looks like you've got a file Lib/test/decimaltestdata/ normalize.decTest (or possible Normalize.decTest). This file shouldn't be present in the distribution (it's outdated). That fixed the problem (or rather, doing a clean reinstall instead of an upgrade install). Thanks, Ronald ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_decimal failure on OSX 10.3
On Thu, Feb 14, 2008 at 11:21 AM, Ronald Oussoren <[EMAIL PROTECTED]> wrote: > Hi, > > I've just filed issue2114 (http://bugs.python.org/issue2114) because > test_decimal.py fails on OSX 10.3 with Python 2.5.2c1. It looks like you've got a file Lib/test/decimaltestdata/normalize.decTest (or possible Normalize.decTest). This file shouldn't be present in the distribution (it's outdated). Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
On 14 Feb, 16:36, "Giampaolo Rodola'" <[EMAIL PROTECTED]> wrote: > Ok, I'll try to take a look at all asyncore/chat reports and try to > summarize them by splitting patches which solve bugs and patches which > add enhancements or functionalities. > > On 14 Feb, 16:12, "Facundo Batista" <[EMAIL PROTECTED]> wrote: > > > > > 2008/2/14, Giampaolo Rodola' <[EMAIL PROTECTED]>: > > > > asyncore and asynchat are in a difficult position right now since a > > > lot of patches for both modules are pending and no decisions are > > > taken. > > > In detail I'm talking about patches 1519, 1541, 2073 and 1736190 which > > > is the most important one since it includes a lot of fixes for other > > > reported issues (e.g. 1740572, 1736101, 909005). > > > I took a look to some of these in other opportunity, and IIRC, the > > main issue here is exactly what you say: lots of issues with problem > > *and* fixes, but some decisions needs to be taken. > > > No decision taken, the pile of issues (and real problems behind them) > > accumulate through time. I think it's a good idea to bring this > > discussion here, and with luck a result will come up regarding them. > > > So, it would be great if you (please) summarize here the problems > > behind those issues and the decisions that must be taken... Thanks! > > > Regards, > > > -- > > . Facundo > > > Blog:http://www.taniquetil.com.ar/plog/ > > PyAr:http://www.python.org/ar/ === Patches for existing issues === - 1736190 which includes fixes for the following issues among other improvements: - 1063924 (asyncore should handle ECONNRESET in send()) - 1736101 (asyncore should handle ECONNABORTED in recv()) - 760475 (handle_error() should call handle_close() instead of close()) - 1740572 (refill_buffer() should call handle_close() rather than close()) - 777588 (wrong "connection refused" behavior on Windows) - 889153 (wrong connect() behavior) - 953599 (asyncore misses socket closes when poll is used) - 1025525 (asyncore.file_dispatcher should not take fd as argument) - 1519 (async_chat.__init__() and asyncore.dispatcher.__init__ parameters inconsistency) - 1541 (Bad OOB data management when using asyncore with select.poll()) - 2073 (asynchat push always sends 512 bytes (ignoring ac_out_buffer_size)) === Open issues with no patches (need review) === - 658749 (asyncore connect() and winsock errors) - 1161031 (neverending warnings from asyncore) === Enhancements & new features === - 1641 (add delayed calls feature) - 1563 (conversion to py3k and some other changes) IMHO the first thing to do should be modifying 1736190 patch to fix the minor issues came out in comments 52767 (re-add simple_producer and fifo classes) and 57581 (look at what is specified in ac_out_buffer_size) and then commit it. I've used that same modified asynchat version in my pyftpdlib project and I can tell that it works pretty good. I guess that Josiah Carlson could do that pretty quickly if he has time to do so. Independently from all a nice thing to do would be adding tests for many asyncore/chat behaviors which currently aren't covered by the test suite. It could be very useful to know if behaviors between different commits remain the same, hence it would be better working on that (the test suite) before committing 1736190. -- Giampaolo ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] int/float freelists vs pymalloc
Christian Heimes <[EMAIL PROTECTED]> wrote: > +1 on focusing on improving pymalloc to handle int and float >object allocations even better I wonder if the int and float types could use a faster internal pymalloc interface. I can't remember the details but I seem to recall that pymalloc must jump through some hoops in order to be safely called from code that used to call PyMem_New, etc. I think locking was one problem but there might be others. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.5.2, release candidate 1
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.5.2 (release candidate 1). This is the second bugfix release of Python 2.5. Python 2.5 is now in bugfix-only mode; no new features are being added. According to the release notes, over 100 bugs and patches have been addressed since Python 2.5.1, many of them improving the stability of the interpreter, and improving its portability. For more information on Python 2.5.2, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.5.2/ Highlights of this new release include: Bug fixes. According to the release notes, at least 100 have been fixed. Highlights of the previous major Python release (2.5) are available from the Python 2.5 page, at http://www.python.org/2.5/highlights.html Enjoy this release, Martin Martin v. Loewis [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5.2 freeze upcoming
> Since I can't change issue assignment I reply here. > Issue 1745035 (which is still open) should concern 2.5.2. Thanks for pointing that out. As the release candidate has been produced already, it's too late for this specific patch to go into 2.5.2. Maybe we can consider it for 2.5.3. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding __format__ to classic classes
Eric Smith wrote: > Are you saying I should call _PyType_Lookup first? No, I think he's saying that you don't need to call _PyType_Lookup at all, because anything that it could find will also be found by PyObject_GetAttr. So just call PyObject_GetAttr and it should Just Work. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Calling a builtin from C code; PEP 3101 format() builtin
Eric Smith wrote: > 1: exposing builtin_format(), probably giving it another name > (PyObject_Format?) and moving it somewhere other than bltinmodule.c. PyObject_Format sounds more like an API for invoking the __format__ lookup mechanism. Maybe something like PyObject_DefaultFormat would be better. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding __format__ to classic classes
On Thu, Feb 14, 2008 at 2:36 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: > Eric Smith wrote: > > Are you saying I should call _PyType_Lookup first? > > No, I think he's saying that you don't need to call > _PyType_Lookup at all, because anything that it could > find will also be found by PyObject_GetAttr. > > So just call PyObject_GetAttr and it should Just Work. In case you missed the final result, that turned out to be wrong too: format(object, "") dies when you do it that way. We debugged this very same issue about a year ago, and that's where the _PyType_Lookup call was found to be the solution. GetAttr should only be used for classic class instances (PyInstance_Check()). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Calling a builtin from C code; PEP 3101 format() builtin
Greg Ewing wrote: > Eric Smith wrote: > >> 1: exposing builtin_format(), probably giving it another name >> (PyObject_Format?) and moving it somewhere other than bltinmodule.c. > > PyObject_Format sounds more like an API for invoking the > __format__ lookup mechanism. Maybe something like > PyObject_DefaultFormat would be better. I see it like: PyObject_Str(o) gives you str(o), PyObject_Unicode(o) gives you unicode(o) so PyObject_Format(o, spec) give you format(o, spec). All 3 of them do things with __special__ methods. Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
Hey everyone, Sorry I haven't been available for this recently, I've been working far too much (10-14 hours/day, 6 days/week, since November) to really do any "fun" programming. Also, sorry for top-posting. As I stated 2+ and 6+ months ago, the patches I submitted 9+ months ago work (I've been using them in my own projects without issue). The only issue with the bugfix/rearrangement that I last heard about with regards to the 2.x stuff was that I removed a class that no one was using in the wild, which I believe Giampaolo added in a subsequent patch in the last couple months. My suggestion: 1. Apply the most recent fixes to 2.6 asyncore/asynchat that Giampaolo has updated. 1.a. Figure out what the hell is up with OOB data, how to handle it, and stop making it use handle_expt(). 2. Use the 2.x -> 3.x tool to convert the fixes over. 3. Apply any 3.x specific fixes (for string/bytes, etc.) to the 3.x branch as necessary (make them global constants in both 2.x and 3.x so that they are easy to track). 4. Consider enhancements to 2.6 if they aren't to big, consider slightly larger enhancements to 3.x. * - Josiah * Scheduled tasks are not a valid enhancement for either; anyone who wants them can trivially add them with their own asyncore.loop() variant and call asyncore.poll() as necessary (I did it in about 15 lines in the summer of 2002, I hope others can do better now). If you want my opinion on other async-related features, feel free to email me directly (use the gmail address you see here, then it ends up in my inbox, not the overflowing python folder). On Thu, Feb 14, 2008 at 9:09 AM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > On 14 Feb, 16:36, "Giampaolo Rodola'" <[EMAIL PROTECTED]> wrote: > > Ok, I'll try to take a look at all asyncore/chat reports and try to > > summarize them by splitting patches which solve bugs and patches which > > add enhancements or functionalities. > > > > On 14 Feb, 16:12, "Facundo Batista" <[EMAIL PROTECTED]> wrote: > > > > > > > > > 2008/2/14, Giampaolo Rodola' <[EMAIL PROTECTED]>: > > > > > > asyncore and asynchat are in a difficult position right now since a > > > > lot of patches for both modules are pending and no decisions are > > > > taken. > > > > In detail I'm talking about patches 1519, 1541, 2073 and 1736190 which > > > > is the most important one since it includes a lot of fixes for other > > > > reported issues (e.g. 1740572, 1736101, 909005). > > > > > I took a look to some of these in other opportunity, and IIRC, the > > > main issue here is exactly what you say: lots of issues with problem > > > *and* fixes, but some decisions needs to be taken. > > > > > No decision taken, the pile of issues (and real problems behind them) > > > accumulate through time. I think it's a good idea to bring this > > > discussion here, and with luck a result will come up regarding them. > > > > > So, it would be great if you (please) summarize here the problems > > > behind those issues and the decisions that must be taken... Thanks! > > > > > Regards, > > > > > -- > > > .Facundo > > > > > Blog:http://www.taniquetil.com.ar/plog/ > > > PyAr:http://www.python.org/ar/ > > > > === Patches for existing issues === > > - 1736190 which includes fixes for the following issues among other > improvements: > - 1063924 (asyncore should handle ECONNRESET in send()) > - 1736101 (asyncore should handle ECONNABORTED in recv()) > - 760475 (handle_error() should call handle_close() instead of > close()) > - 1740572 (refill_buffer() should call handle_close() rather than > close()) > - 777588 (wrong "connection refused" behavior on Windows) > - 889153 (wrong connect() behavior) > - 953599 (asyncore misses socket closes when poll is used) > - 1025525 (asyncore.file_dispatcher should not take fd as argument) > > - 1519 (async_chat.__init__() and asyncore.dispatcher.__init__ > parameters inconsistency) > - 1541 (Bad OOB data management when using asyncore with > select.poll()) > - 2073 (asynchat push always sends 512 bytes (ignoring > ac_out_buffer_size)) > > > === Open issues with no patches (need review) === > > - 658749 (asyncore connect() and winsock errors) > - 1161031 (neverending warnings from asyncore) > > > === Enhancements & new features === > > - 1641 (add delayed calls feature) > - 1563 (conversion to py3k and some other changes) > > > IMHO the first thing to do should be modifying 1736190 patch to fix > the minor issues came out in comments 52767 (re-add simple_producer > and fifo classes) and 57581 (look at what is specified in > ac_out_buffer_size) and then commit it. > I've used that same modified asynchat version in my pyftpdlib project > and I can tell that it works pretty good. > I guess that Josiah Carlson could do that pretty quickly if he has > time to do so. > > Independently from all a nice thing to do would be adding tests for > many asyncore/chat behaviors which currently aren't co
