> As to exposing Py_AddPendingCall() as sys.addpendingcall, that might be opening a can of worms.  Injecting code into the eval loop at some arbitrary ("soon") future time requires care and the code isn't well exercised historically (much like subinterpreters).

Well, it's absolutely the same mechanism that signal handlers use.  It looks like this can of works has been open for a pretty long time now :)

The whole point of adding this API is to make it possible for asyncio to work with the "signals" module not from the main thread.  I expect 99.9% of other use cases to be either about signals or other super low-level stuff that needs the main thread (off the top of my head I can't name any :))

> It also adds burden on other Python implementations.

Python signal processing *requires* users callbacks to be executed in the main thread (whereas Unix can deliver the signal to any thread, potentially). Therefore I think that any alternative Python implementation should have a mechanism to schedule code execution in the main thread.

> My point is, let's think this through before adding sys.addpendingcall(). :)  Is there another way this could be done that doesn't open a can of worms?

Maybe. One of such ways is to enable signal.signal calls from non-main threads.  But I'm not sure this is possible for all platforms we support. Maybe Victor or Andrew can shed more light on this.

> Also, at the very least it should probably be a "private" function (i.e sys._addpendingcall).

Maybe.  The problem is that asyncio must work the same on PyPy, which means that the sys API it uses should be available on PyPy too.  In which case, they will kind of have to add it, which means that there's no point in making it semi-private.  OTOH, I wouldn't mind sys._addpendingcall(), as long as PyPy implements it.