Ross Cohen wrote: > I agree that it should go into the select module, but not as a seperate > set of calls. epoll is strictly better than poll. kqueue is strictly > better than poll. Windows has its own completion ports API. Why should > an application developer have to detect what platform they are running on?
Because the APIs have different semantics. Design some API for epoll, and make it replace select or poll (your choice), and I create you an application that breaks under your poll "emulation". If a complete emulation was possible, the OS developers would not have invented a new API. > Why not simply provide the best implementation for the platform through the > python API everyone is already using? Well, what *is* the API everyone is already using? This is really something for a higher-level API that assumes a certain processing model (unless the OS API, which assumes no processing model). Python has a tradition of exposing system APIs *as is*, with no second-guessing either the OS developers, nor the application developers. Then, we put a unified API *on top* of that. For event processing, the standard library always provided asyncore/asynchat, although people don't like it. I'm sure the Twisted people would integrate epoll in no time, and with no API change for *their* users. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
