This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author chrysn
Recipients chrysn, giampaolo.rodola, josiahcarlson, stutzbach
Date 2012-09-20.11:31:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1348140666.86.0.948985366577.issue15978@psf.upfronthosting.co.za>
In-reply-to
Content
i'm aware this is ambitious, and hope that at least the individual sub-agendas will be manageable. as for vague, i can enhance it (i'd start refining the individual sub-agendas -- or do you think the "big picture" needs more details too?).

integration of frameworks is hard, i know. for some libraries, it might not even be feasible, or it could be that it'd be easier to write a new server than integrating into the existing one. (eg it might be easier to refactor http servers into a generic and a blocking part first, and then offer a http.server.AsyncServer in parallel to the existing implementation). that's why i'd like to try to get a rough roadmap instead of hacking ahead :-)

nevertheless, the current situation is not satisfying -- we have a versatile http client module, and yet who wants to fetch asynchronously is left with a stub implementation in the asyncore docs. that's not what one would expect from the "batteries included" catchphrase.

we don't need all of that implemented *right now*, but maybe we can do better than implementing it never.
History
Date User Action Args
2012-09-20 11:31:06chrysnsetrecipients: + chrysn, josiahcarlson, giampaolo.rodola, stutzbach
2012-09-20 11:31:06chrysnsetmessageid: <1348140666.86.0.948985366577.issue15978@psf.upfronthosting.co.za>
2012-09-20 11:31:06chrysnlinkissue15978 messages
2012-09-20 11:31:05chrysncreate