On Fri, Oct 12, 2012 at 3:43 PM, Guido van Rossum guido@python.org wrote:
On Thu, Oct 11, 2012 at 6:38 PM, Mark Adam dreamingforward@gmail.com wrote:
Here's the thing: the underlying O.S is always handling two major I/O channels at any given time and it needs all it's attention to do this: the GUI and one of the following (network, file) I/O. You can shuffle these around all you want, but somewhere the O.S. kernel is going to have to be involved, which means either portability is sacrificed or speed if one is going to pursue and abstract, unified async API.
I'm convinced that the OS has to get involved. I'm not convinced that it will get in the way of designing an abstract unified API -- however that API will have to be more complicated than the kind of event loop that *only* handles network I/O or the kind that *only* handles GUI events.
Yes, however, as suggested in my other message, there are three desires: {"cross-platform (OS) portability", "speed", "unified API"}, but you can only pick two.
One of these has to be sacrificed because there are users for all of those.
I think such a decision must be "deferred() "to some "Future(Python4000)" in order to succeed at making "Grand Unified Theory" for hardware/OS/python synchronization.
(For the record, I do think it is possible, and indeed that is exactly what I'm working on. To make it work will require a compelling, unified object model, forwarding the art of Computer Science...)
markj