[Python-ideas] PEP 3156 feedback

[Guido van Rossum]

On Wed, Dec 19, 2012 at 10:55 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Why not let implementations raise NotImplementedError when they don't
> want to support certain use cases?

That's always a last resort, but the problem is that an app or library
can't be sure that everything will work, and the failure might be
subtle and late.

That said, my remark about the loop needing to be wholly threadsafe
was misguided. I think there are two reasonable policies with regards
to thread that any reasonable implementation could follow:

1. There's only one loop, it runs in a dedicated thread, and other
threads can only use call_soon_threadsafe().

2. There's (potentially) a loop per thread, and these are effectively
independent. (TBD: How would these pass work or results between one
another? Probably by calling call_soon_threadsafe() back and forth.)

The default implementation actually takes a halfway position: it
supports (2), but you must manually call init_event_loop() in each
thread except for the main thread, and you must call run() in each
thread, including the main thread. The requirement to call
init_event_loop() is to prevent code running in some random thread
trying to schedule callback, which would never run because the thread
isn't calling run().

When we get further along we may have a compliance test suite,
separate from the unittests (I am working on unittests but I'm aware
they aren't at all thorough yet).

> Is it the plan that code written for an event loop will always work with
> another one?

The plan is to make it easy to write code that will work with all (or
most) event loops, without making it impossible to write code that
depends on a specific event loop implementation. This is Python's
general attitude about platform-specific APIs.

> Will tulip offer more than the GCD of the other event loops?

People writing PEP 3156 compliant implementations on top of some other
event loop, whether it's Twisted or libuv, may have to emulate some
functionality, and there will also be some functionality that their
underlying loop supports that PEP 3156 doesn't. The goal is to offer a
wide enough range of features that it's possible to write many useful
types of apps without resorting to platform-specific APIs, and to make
these fast enough.

But if an app knows it will only be used with a certain loop
implementation it is free to use extra APIs that only that loop
offers. There's still a benefit in that situation: the app may be tied
to a platform, but it may still want to use some 3rd party libraries
that also require event loop integration, and by conforming to PEP
3156 the platform's loop implementation can ensure that such libraries
actually work and interact with the rest of the app in a reasonable
manner. (In particular, they should all use the same Future and Task
classes.)

-- 
--Guido van Rossum (python.org/~guido)