
On 6 December 2017 at 12:51, Eric Snow <ericsnowcurrently@gmail.com> wrote:
Hi all,
I've finally updated PEP 554. Feedback would be most welcome. The PEP is in a pretty good place now and I hope to we're close to a decision to accept it. :)
Nice updates! I like this version.
In addition to resolving the open questions, I've also made the following changes to the PEP:
* put an API summary at the top and moved the full API description down * add the "is_shareable()" function to indicate if an object can be shared * added None as a shareable object
Regarding the open questions:
* "Leaking exceptions across interpreters"
I chose to go with an approach that effectively creates a traceback.TracebackException proxy of the original exception, wraps that in a RuntimeError, and raises that in the calling interpreter. Raising an exception that safely preserves the original exception and traceback seems like the most intuitive behavior (to me, as a user). The only alternative that made sense is to fully duplicate the exception and traceback (minus stack frames) in the calling interpreter, which is probably overkill and likely to be confusing.
My one suggestion here would be to consider a dedicated exception type like "interpreters.SubinterpreterError", rather than re-using RuntimeError directly. That way you can put the extracted traceback on a named attribute, and retain the option of potentially adding subinterpreter awareness to the traceback module in the future.
* "Initial support for buffers in channels"
I chose to add a "SendChannel.send_buffer(obj)" method for this. Supporting buffer objects from the beginning makes sense, opening good experimentation opportunities for a valuable set of users. Supporting buffer objects separately and explicitly helps set clear expectations for users. I decided not to go with a separate class (e.g. MemChannel) as it didn't seem like there's enough difference to warrant keeping them strictly separate.
FWIW, I'm still strongly in favor of support for passing (copies of) bytes objects via channels. Passing objects to SendChannel.send() is obvious. Limiting it, for now, to bytes (and None) helps us avoid tying ourselves strongly to any particular implementation (it seems like all the reservations were relative to the implementation). So I do not see a reason to wait.
Aye, the split sending API with a merged receive API works for me.
* "Pass channels explicitly to run()?"
I've applied the suggested solution (make "channels" an explicit keyword argument).
Cool. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia