On Sat, Oct 13, 2012 at 1:54 PM, Laurens Van Houtven email@example.com wrote:
On Sat, Oct 13, 2012 at 1:22 AM, Guido van Rossum firstname.lastname@example.org wrote:
[Hopefully this is the last spin-off thread from "asyncore: included batteries don't fit"]
So it's totally unfinished?
At the time, the people I talked to placed significantly more weight in "explain why this is necessary" than "get me something I can play with".
Do you feel that there should be less talk about rationale?
No, but I feel that there should be some actual specification. I am also looking forward to an actual meaty bit of example code -- ISTR you mentioned you had something, but that it was incomplete, and I can't find the link.
Just examples of how it would work, nothing hooked up to real code. My memory of it is more of a drowning-in-politics-and-bikeshedding kind of thing, unfortunately :) Either way, I'm okay with letting bygones be bygones and focus on how we can get this show on the road.
It's not that there's *no* reference to IO: it's just that that reference is abstracted away in data_received and the protocol's transport object, just like Twisted's IProtocol.
The words "data_received" don't even occur in the PEP.
What thread should I reply in about the pull APIs?
I just want to make sure that we don't *completely* paint ourselves into the wrong corner when it comes to that.
I don't think we have to worry about it too much. Any reasonable API I can think of makes this completely doable.
But I'm really hoping you'll make good on your promise of redoing async-pep, giving some actual specifications and example code, so I can play with it.
- The async API of the future is very important, and too important to be
left to chance.
Could not agree more.
- It requires a lot of very experienced manpower.
I'm sitting on the sidelines, wishing I had much of either, because of point number 1.
- It requires a lot of effort to handle the hashing out of it (as we're
doing here) as well as it deserves to be.
I'll take as proactive a role as I can afford to take in this process, but I don't think I can do it by myself. Furthermore, it's a risk nobody wants to take: a repeat performance wouldn't be good for anyone, in particular not for Python nor myself.
I've asked JP Calderone and Itamar Turner-Trauring if they would be interested in carrying this forward professionally, and they have tentatively said yes. JP's already familiar with a large part of the problem space with the implementation of the ssl module. JP and Itamar have worked together for years and have recently set up a consulting firm.
Given that this is emphatically important to Python, I intend to apply for a PSF grant on their behalf to further this goal. Given their experience in the field, I expect this to be a fairly low risk endeavor.
I like this idea. There are some problems spare time isn't enough to solve.
I can't think of many people as qualified for the task.
-- --Guido van Rossum (python.org/~guido)
-- cheers lvh
Python-ideas mailing list Pythonemail@example.com http://mail.python.org/mailman/listinfo/python-ideas