> (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 _______________________________________________ Python-win32 mailing list Python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
