[issue1641] asyncore delayed calls feature

STINNER Victor added the comment: asyncore documentation now starts with this note (which was approved by the asyncore maintainer): "This module exists for backwards compatibility only. For new code we recommend using asyncio." Since asyncio is now part of the stdlib, I don't think that it's w

[issue1641] asyncore delayed calls feature

Guido van Rossum added the comment: Now asyncio/tulip has landed in the 3.4 stdlib, asyncore will be effectively obsolete starting 3.4 (even if we don't mark it so). Its presence is required for backwards compatibility, but that doesn't mean we should encourage people to keep using it by addin

[issue1641] asyncore delayed calls feature

Giampaolo Rodola' added the comment: I'm not sure how many users asyncore has out there nowadays, but if it has to stay in the stdlib then I see some value in adding a scheduler to it because it is an essential component. If this is still desirable I can restart working on a patch, although I'

[issue1641] asyncore delayed calls feature

Guido van Rossum added the comment: A new implementation is part of Tulip (tulip/selectors.py); once Tulip is further along it will be a candidate for inclusion in the stdlib (as socket.py) regardless of whether tulip itself will be accepted. I have no plans to work on asyncore. On Fri, Mar 8, 2

[issue1641] asyncore delayed calls feature

Terry J. Reedy added the comment: Where does this issue stand now? Did the applied sched patch supersede the proposed asyncore patch? Is enhancing asyncore still on the table given Guido's proposed new module? -- nosy: +terry.reedy versions: +Python 3.4 -Python 3.3 __

[issue1641] asyncore delayed calls feature

Roundup Robot added the comment: New changeset 59f0e6de54b3 by Giampaolo Rodola' in branch 'default': (sched) when run() is invoked with blocking=False return the deadline of the next scheduled call in the scheduler; this use case was suggested in http://bugs.python.org/issue1641#msg149453 htt

[issue1641] asyncore delayed calls feature

Antoine Pitrou added the comment: > while 1: > asyncore.loop(timeout=1.0, count=1) # count=1 makes loop() return after > 1 loop > scheduler.run(blocking=False) Isn't that both ugly and imprecise? The right way to do it is to set the timeout of the select() call according to the

[issue1641] asyncore delayed calls feature

Giampaolo Rodola' added the comment: Now that I think of it maybe some kind of wrapper would still be necessary. As of right now, we'd do something like this. At the core we would have: import asyncore, asynchat, sched # global scheduler = sched.scheduler() while 1: asyncore.loop(timeout=

[issue1641] asyncore delayed calls feature

Antoine Pitrou added the comment: > With issue13449 fixed I think we can now provide this functionnality by > adding a specific section into asyncore doc which explains how to use > asyncore in conjunction with sched module. How would it work? -- _

[issue1641] asyncore delayed calls feature

Giampaolo Rodola' added the comment: With issue13449 fixed I think we can now provide this functionnality by adding a specific section into asyncore doc which explains how to use asyncore in conjunction with sched module. As such, asyncore.py itself won't need any change. --

[issue1641] asyncore delayed calls feature

Giampaolo Rodola' added the comment: This patch is now available as a recipe for python 2.x: http://code.activestate.com/recipes/577808-asyncore-scheduler/ -- versions: +Python 3.3 -Python 3.2 ___ Python tracker __

[issue1641] asyncore delayed calls feature

Changes by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue1641] asyncore delayed calls feature

Daniel Stutzbach added the comment: On Tue, May 11, 2010 at 11:55 AM, Giampaolo Rodola' wrote: > Moreover, reset() and delay() methods are not implemented in sched. > > Other problems which comes to mind are: you can't easily know whether a call > has already been cancelled, you can't manually

[issue1641] asyncore delayed calls feature

Antoine Pitrou added the comment: > Adding a call: > > scheduler = sched.scheduler(time.time, time.sleep) > scheduler.enter(10, 1, function, (arg,)) > > ...vs: > > asyncore.call_later(10, function, arg) I don't really see the difference. How hard it is to build a scheduler object at startup

[issue1641] asyncore delayed calls feature

Giampaolo Rodola' added the comment: > Let the user leverage the existing scheduler API. Cut out > scheduled_task and call_later, which just wraps the scheduler API. > The user can simply call scheduled_tasks.enter() or > scheduled_tasks.cancel(). It's one less API for them to learn and >

[issue1641] asyncore delayed calls feature

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 tracke

[issue1641] asyncore delayed calls feature

Daniel Stutzbach added the comment: I like the idea of leveraging the sched module. It encapsulates the priority queue, allowing the user to be agnostic to the underlying data structure. If someday we have a data structure in the collections module that provides an efficient delete-key oper

[issue1641] asyncore delayed calls feature

Antoine Pitrou added the comment: I agree with the points raised against Josiah's patch. I'm not sure O(n) cancellation is really a concern. The main focus of optimization should be the scheduler's loop itself, and both approaches have an O(log n) complexity there AFAICT. Also, the cancellati

[issue1641] asyncore delayed calls feature

Giampaolo Rodola' added the comment: Assuming this is still desirable I'd really like to move forward with this issue. The current situation is that we have two patches. My patch pros: * affects asyncore.py only * (imho) cleaner, as it just adds one class * stable, as it has been

[issue1641] asyncore delayed calls feature

Jim Fulton added the comment: On Apr 2, 2009, at 3:35 PM, Josiah Carlson wrote: > > 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 subclas

[issue1641] asyncore delayed calls feature

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 sub

[issue1641] asyncore delayed calls feature

Tres Seaver added the comment: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guido van Rossum wrote: > ISTR that Zope has or had significant monkeypatches to at least one of > asyncore/asynchat. The resulting coupling between Zope and asyn* has > meant that the de-facto API of asyn* was much m

[issue1641] asyncore delayed calls feature

Jim Fulton added the comment: On Apr 2, 2009, at 1:27 PM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > [Guido] >>> Looking back, I think Zope and Medusa should have adopted and >>> evolved >>> their own copy of asynchat a long time ago... > > [Jim] >> This statement is

[issue1641] asyncore delayed calls feature

Guido van Rossum added the comment: [Guido] >> Looking back, I think Zope and Medusa should have adopted and evolved >> their own copy of asynchat a long time ago... [Jim] > This statement is puzzling.  No big deal, but I'm curious why you say > this. ISTR that Zope has or had significant monk

[issue1641] asyncore delayed calls feature

Tres Seaver added the comment: Sidnei da Silva had to put some "straddling" code in the Zope2 trunk to workaround the 2.6 changes to asyncore / asynchat: - http://svn.zope.org/Zope/?rev=91981&view=rev - http://svn.zope.org/Zope/?rev=92023&view=rev -- nosy: +tseaver __

[issue1641] asyncore delayed calls feature

Jim Fulton added the comment: For the record, afaict, Zope wasn't broken by this. Supervisor isn't part of Zope. -- ___ Python tracker ___ ___

[issue1641] asyncore delayed calls feature

Jim Fulton added the comment: > Looking back, I think Zope and Medusa should have adopted and evolved > their own copy of asynchat a long time ago... This statement is puzzling. No big deal, but I'm curious why you say this. -- nosy: +j1m ___ Pytho

[issue1641] asyncore delayed calls feature

Changes by Daniel Stutzbach : -- nosy: +stutzbach ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue1641] asyncore delayed calls feature

Guido van Rossum added the comment: Looking back, I think Zope and Medusa should have adopted and evolved their own copy of asynchat a long time ago... -- ___ Python tracker ___

[issue1641] asyncore delayed calls feature

Chris McDonough added the comment: I am the developer of Supervisor (http://supervisord.org) which depends on (and extends) Medusa 0.5.4, which itself depends on some implementation details of pre-2.6 versions of asynchat (e.g. "ac_out_buffer"). I need to make sure Supervisor works with Python

[issue1641] asyncore delayed calls feature

Guido van Rossum added the comment: Josiah, there's no need to get all defensive and passive-aggressive about it. I'm just reporting about strong feelings that were brought up at the language summit -- to my surprise too! Admitting somebody made a mistake would be step one (and I'll gladly admit

[issue1641] asyncore delayed calls feature

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

[issue1641] asyncore delayed calls feature

Giampaolo Rodola' added the comment: I don't know what are the problems experienced by the Zope folks (is there a place where this is discussed?) but I can guess that they're having problems with asynchat rather than with asyncore, since the latter hasn't changed too much between 2.5 and 2.6 exc

[issue1641] asyncore delayed calls feature

Guido van Rossum added the comment: Well arguably asyncore is unsalvageable due to the undocumented internals issue, and we sure know a bit more about how to design a *good* asynchronous API than we did when asyncore was created. (One hint: don't make subclassing part of your API.) The Zope fol

[issue1641] asyncore delayed calls feature

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

[issue1641] asyncore delayed calls feature

Guido van Rossum added the comment: Josiah, you need an attitude adjustment. The breakage of asyncore in 2.6 was real and is now harming adoption of 2.6 by those folks (who are by nature not early adopters -- their customers are typical enterprise users). Talk to Tres Seaver and Jim Fulton. The

[issue1641] asyncore delayed calls feature

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 tha

[issue1641] asyncore delayed calls feature

Guido van Rossum added the comment: I guess the Zope developers aren't that tuned in to core Python developement. They were sorely bitten. I don't think you can claim that users should be tuned in to python-dev just to assure their favorite module isn't removed or broken. It behooves you to r

[issue1641] asyncore delayed calls feature

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 com

[issue1641] asyncore delayed calls feature

Guido van Rossum added the comment: At the language summit last Thursday there was widespread disappointment with the changes to asyncore.py in 2.6, which broke almost all code that actually uses it. Unfortunately, the documented API is lame, so everybody depended on undocumented internals, and

[issue1641] asyncore delayed calls feature

Changes by Josiah Carlson : Removed file: http://bugs.python.org/file13238/scheduler_partial.patch ___ Python tracker ___ ___ Python-bugs-list

[issue1641] asyncore delayed calls feature

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,

[issue1641] asyncore delayed calls feature

Changes by Kevin Watters : -- nosy: +kevinwatters ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue1641] asyncore delayed calls feature

Changes by intgr : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-lis

[issue1641] asyncore delayed calls feature

Changes by intgr : -- nosy: +intgr ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailma

[issue1641] asyncore delayed calls feature

Changes by Giampaolo Rodola' : Removed file: http://bugs.python.org/file8976/patch.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue1641] asyncore delayed calls feature

Giampaolo Rodola' added the comment: A new patch is in attachment. Changes from the previous one (Sep 2008): - renamed "deafult_tasks" global list to "scheduled_tasks" - loop(), scheduler() and close_all() have a new "tasks" keyword argument defaulting to None - close_all() other than itera

[issue1641] asyncore delayed calls feature

Josiah Carlson added the comment: Here's a better patch without tabs. Added file: http://bugs.python.org/file13238/scheduler_partial.patch ___ Python tracker ___

[issue1641] asyncore delayed calls feature

Changes by Josiah Carlson : Removed file: http://bugs.python.org/file13237/scheduler_partial.patch ___ Python tracker ___ ___ Python-bugs-list

[issue1641] asyncore delayed calls feature

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

[issue1641] asyncore delayed calls feature

Guido van Rossum added the comment: You could solve this with a "reserved" keyword argument _tasks. Or you could have two different factory methods, call_later_with_tasks() and call_later(). ___ Python tracker

[issue1641] asyncore delayed calls feature

Giampaolo Rodola' added the comment: > You'd also have to pass the tasks list to the scheduler() call and the > call_later() constructor. Defaulting to a global is fine. Unless I change the current API I can't add a new optional arguments to call_later constructor because it already uses *args

[issue1641] asyncore delayed calls feature

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

[issue1641] asyncore delayed calls feature

Guido van Rossum added the comment: The idea is to be able (whether you see a use case or not) to use different tasks lists simultaneously. Messing with globals is the worst possible API for that. All you need is to add a tasks=None argument to the loop() signature, rename the global tasks lis

[issue1641] asyncore delayed calls feature

Giampaolo Rodola' added the comment: > Giampaolo, I'm concerned that your patch uses a global 'tasks' list > which cannot be overriden. Shouldn't loop() accept an optional task > list argument, as it already does with the socket map? That would keep > with the spirit of asyncore and make thin

[issue1641] asyncore delayed calls feature

Forest Wilkinson added the comment: I'm looking forward to having this functionality in asyncore. It would help me remove some unwanted hackery from my own code. Giampaolo, I'm concerned that your patch uses a global 'tasks' list which cannot be overriden. Shouldn't loop() accept an optional

[issue1641] asyncore delayed calls feature

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 equival

[issue1641] asyncore delayed calls feature

Changes by Giampaolo Rodola' <[EMAIL PROTECTED]>: -- components: +Library (Lib) -Installation versions: +Python 2.7, Python 3.1 -Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> _

[issue1641] asyncore delayed calls feature

Changes by Giampaolo Rodola' <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file8977/asyncore.py ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue1641] asyncore delayed calls feature

Giampaolo Rodola' <[EMAIL PROTECTED]> added the comment: I try to revamp this issue by attaching a new patch which improves the work I did against asyncore last time. The approach proposed in this new patch is the same used in the upcoming pyftpdlib 0.5.0 version which has been largely tested and

[issue1641] asyncore delayed calls feature

Josiah Carlson <[EMAIL PROTECTED]> added the comment: Generally speaking, delayed calls, and/or a practical scheduling algorithm are useful for async servers. Since 2.6 and 3.0 are on feature freeze right now, this is going to have to wait for 2.7 and 3.1 . I'll make sure to get something like

[issue1641] asyncore delayed calls feature

Changes by Mark Blakeney <[EMAIL PROTECTED]>: -- nosy: +markb __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe:

[issue1641] asyncore delayed calls feature

Changes by Forest Wilkinson <[EMAIL PROTECTED]>: -- nosy: +forest __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscri

[issue1641] asyncore delayed calls feature

Daniel Arbuckle <[EMAIL PROTECTED]> added the comment: Unfortunately, it appears that asyncore and asynchat are caught in a deadlock, in which it is demanded that certain patches be applied before any further work is done, but nobody (even among those making the demands) is both willing and able

[issue1641] asyncore delayed calls feature

Giampaolo Rodola' <[EMAIL PROTECTED]> added the comment: Sean, I already tried to raise two discussion attempts on both lists here: http://groups.google.com/group/python-dev2/browse_thread/thread/ecbf4d38a868d4f/ec5c7dbd40664b7f?lnk=gst&q=asyncore+giampaolo ...and here: http://groups.google.com/g

[issue1641] asyncore delayed calls feature

Sean Reifschneider <[EMAIL PROTECTED]> added the comment: Giampaolo: Can you pleaes bring this up on python-dev or the normal python mailing list for further discussion on the issue? -- assignee: -> akuchling keywords: +patch nosy: +akuchling, jafo priority: -> normal type: -> feature

[issue1641] asyncore delayed calls feature

Facundo Batista added the comment: The issue #2006 (asyncore loop lacks timers and work tasks) was closed as duplicate of this one... noting this just for reference. -- nosy: +facundobatista __ Tracker <[EMAIL PROTECTED]>

[issue1641] asyncore delayed calls feature

Guido van Rossum added the comment: If you want attention, please post to python-dev if you didn't already. Or widen the audience to python-list if you want to. -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __

[issue1641] asyncore delayed calls feature

Changes by Daniel Arbuckle: -- nosy: +djarb __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue1641] asyncore delayed calls feature

Changes by Giampaolo Rodola': Added file: http://bugs.python.org/file8977/asyncore.py __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing lis

[issue1641] asyncore delayed calls feature

Changes by Giampaolo Rodola': Added file: http://bugs.python.org/file8976/patch.diff __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list

[issue1641] asyncore delayed calls feature

New submission from Giampaolo Rodola': Hi, I post this message here in the hope someone using asyncore could review this. Since the thing I miss mostly in asyncore is a system for calling a function after a certain amount of time, I spent the last 3 days trying to implement this with the hopes th