On 2012-09-10, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote: > On Sun, 9 Sep 2012 20:07:51 -0400, "Dustin J. Mitchell" ><dus...@v.igoro.us> declaimed the following in > gmane.comp.python.general: > >> >> My proposal met with near-silence, and I didn't pursue it. Instead, I >> did what any self-respecting hacker would do - I wrote up a framework, >> uthreads [4], that implemented my idea. This was initially a simple >> trampoline scheduler, but I eventually refactored it to run atop >> Twisted, since that's what I use. To my knowledge, it's never been >> used. >> > So for your small attempt to hide an event-driven dispatcher, one > has to load a massive event-driven library. Some years ago I tried to > make sense of Twisted and failed badly. Maybe it makes sense to those > raised on UNIX style select() (where practically anything that involved > data transfer over some sort of channel could be tested -- but doesn't > work as such on Windows where only network sockets can be used, file i/o > needs to use a different call), >>
I think the idea behind the PEP is to facilitate modularisation of event driven frameworks into dispatchers and libraries that are suitable for running within dispatchers. When you say a 'massive-event driven library' I guess you mean something liek Twisted. I don't have much experience with Twisted but having looked at it a bit my impression is that it is so large because it includes many components that are not essential for every user. I guess that the reason for keeping those components in Twisted rather than as separate projects is not so much because every user needs them but because many of them are implemented in a way that makes them not much use outside of Twisted. The idea that Dustin is proposing is that in the same way that a library might declare a subset of its API to be thread-safe, and so usable with threading frameworks, a library could expose a PEP-XXX compliant interface for use with a PEP-XXX compliant dispatcher. If implemented that should facilitate the creation of minimal dispatchers and minimal standard components that can run within those dispatchers. This would mean that it wouldn't be necessary to make massive event-driven libraries but rather smaller interchangeable libraries. For example, it might facilitate the creation of a Windows-specific dispatcher that would be able to use the best underlying Windows APIs while also benefitting from any PEP-XXX compliant libraries that would work with any other dispatcher. >> As I get to work on the PEP, I'd like to hear any initial reactions to the >> idea. I don't have much experience with the event-driven frameworks but having made a couple of simple scripts using gevent/Twisted my experience is that learning to use these frameworks is hard, largely because of the number of framework- specific concepts that are needed to make simple examples work. I would expect that giving each framework a relatively standardised interface would make them much easier to learn. Oscar -- http://mail.python.org/mailman/listinfo/python-list
