[Python-Dev] PEP 554 v4 (new interpreters module)
ncoghlan at gmail.com
Wed Dec 6 01:49:07 EST 2017
On 6 December 2017 at 12:51, Eric Snow <ericsnowcurrently at 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).
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev