Python Asynchronous I/O library (pyasynchio) [currently win-only]

[Vladimir Sukhoy]

> (but I'm not sure writing large if-else trees and state machines is that
> much easier than implementing hook methods,
Yes, but the decision about how exactly to do that is up to library
user. I tried to build library which can be easily plugged  into
existing code w/o need for serious reengineering or changing design.

Maybe there is a reason to build OO framework similar to asyncore on
top of apoll class, I will consider it.

>  whether you know much
> about programming or not.  have you considered the case where you
> want your program to handle *different* protocols?  how do you
> associate state with sockets in your programming model?)
If there is a need to associate state with socket itself, it can be
done with simple global dictionary, or one can use "act" (Asynchronous
Completion Token) parameter (which defaults to None and is passed in
completion dict) which is present in each of the methods which start
asynch operation, it can be used to pass state information along (it
may be even more convenient).



> 
> (and why return dictionaries?  wouldn't an ordinary object be a better
> choice in this case?  evt['type'] isn't really that pythonic compared to
> evt.type.  an attribute-based approach also lets you delay construction
> of Python objects until the client code actually attempts to use it).
Yes, you are right, I considered attribute-based approach, it will be
used together with dictionary-based in future versions. As for delayed
construction I do not think that there is a big deal in using it in
this particular library.

> 
> (and given that the users will have to check the type and success fields
> for every single event, wouldn't it be better to return those as separate
> values: "for op, ok, event in apoll.poll(): if op == '...': ...")
Thanks, great idea.

-- 
Sincerely,
Vladimir Sukhoy