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
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
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
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,
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
Roundup Robot devn...@psf.upfronthosting.co.za 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
Giampaolo Rodola' g.rod...@gmail.com 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.
Antoine Pitrou pit...@free.fr 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?
--
Giampaolo Rodola' g.rod...@gmail.com 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:
Antoine Pitrou pit...@free.fr 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
Giampaolo Rodola' g.rod...@gmail.com 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
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1641
___
___
Python-bugs-list
Giampaolo Rodola' g.rod...@gmail.com 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
Antoine Pitrou pit...@free.fr 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
Daniel Stutzbach dan...@stutzbachenterprises.com added the comment:
On Tue, May 11, 2010 at 11:55 AM, Giampaolo Rodola'
rep...@bugs.python.org 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
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.
--
Antoine Pitrou pit...@free.fr 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,
Daniel Stutzbach dan...@stutzbachenterprises.com 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
Giampaolo Rodola' g.rod...@gmail.com 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
*
Jim Fulton j...@zope.com 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
Jim Fulton j...@zope.com added the comment:
For the record, afaict, Zope wasn't broken by this. Supervisor isn't
part of Zope.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1641
___
Tres Seaver tsea...@users.sourceforge.net 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=91981view=rev
- http://svn.zope.org/Zope/?rev=92023view=rev
--
nosy:
Guido van Rossum gu...@python.org 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
Jim Fulton j...@zope.com added the comment:
On Apr 2, 2009, at 1:27 PM, Guido van Rossum wrote:
Guido van Rossum gu...@python.org 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
Tres Seaver tsea...@agendaless.com 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
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
Jim Fulton j...@zope.com added the comment:
On Apr 2, 2009, at 3:35 PM, Josiah Carlson wrote:
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
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).
Guido van Rossum gu...@python.org 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
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
Guido van Rossum gu...@python.org 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
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
Guido van Rossum gu...@python.org 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
Giampaolo Rodola' billiej...@users.sourceforge.net 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
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,
Guido van Rossum gu...@python.org 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
Guido van Rossum gu...@python.org 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 rep...@bugs.python.org
http://bugs.python.org/issue1641
Changes by Daniel Stutzbach dan...@stutzbachenterprises.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1641
___
___
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
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
___
Guido van Rossum gu...@python.org 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
Changes by intgr ma...@juffo.org:
--
nosy: +intgr
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1641
___
___
Python-bugs-list mailing list
Changes by intgr ma...@juffo.org:
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1641
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Kevin Watters kevinwatt...@gmail.com:
--
nosy: +kevinwatters
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1641
___
___
Giampaolo Rodola' billiej...@users.sourceforge.net 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
Guido van Rossum gu...@python.org 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
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.
Giampaolo Rodola' billiej...@users.sourceforge.net 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
Guido van Rossum gu...@python.org 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 rep...@bugs.python.org
Josiah Carlson josiahcarl...@users.sourceforge.net 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
Changes by Josiah Carlson josiahcarl...@users.sourceforge.net:
Removed file: http://bugs.python.org/file13237/scheduler_partial.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1641
___
Josiah Carlson josiahcarl...@users.sourceforge.net added the comment:
Here's a better patch without tabs.
Added file: http://bugs.python.org/file13238/scheduler_partial.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1641
Giampaolo Rodola' billiej...@users.sourceforge.net 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
-
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
Removed file: http://bugs.python.org/file8976/patch.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1641
___
Forest Wilkinson for...@users.sourceforge.net 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.
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
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
Changes by Giampaolo Rodola' [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file8977/asyncore.py
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1641
___
Changes by Giampaolo Rodola' [EMAIL PROTECTED]:
--
components: +Library (Lib) -Installation
versions: +Python 2.7, Python 3.1 -Python 2.6
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1641
___
Changes by Mark Blakeney [EMAIL PROTECTED]:
--
nosy: +markb
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1641
__
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Forest Wilkinson [EMAIL PROTECTED]:
--
nosy: +forest
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1641
__
___
Python-bugs-list mailing list
Unsubscribe:
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
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=gstq=asyncore+giampaolo
...and here:
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
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]
http://bugs.python.org/issue1641
Changes by Daniel Arbuckle:
--
nosy: +djarb
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1641
__
___
Python-bugs-list mailing list
Unsubscribe:
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]
http://bugs.python.org/issue1641
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
Changes by Giampaolo Rodola':
Added file: http://bugs.python.org/file8976/patch.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1641
__
___
Python-bugs-list mailing list
69 matches
Mail list logo
