On 6 December 2017 at 12:51, Eric Snow <ericsnowcurren...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
