[Python-Dev] Timeout for PEP 550 (original) (raw)
[Python-Dev] Timeout for PEP 550 / Execution Context discussion
Ethan Furman ethan at stoneleaf.us
Wed Oct 18 14:10:46 EDT 2017
- Previous message (by thread): [Python-Dev] Timeout for PEP 550 / Execution Context discussion
- Next message (by thread): [Python-Dev] Timeout for PEP 550 / Execution Context discussion
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 10/18/2017 10:50 AM, Yury Selivanov wrote:
On Wed, Oct 18, 2017 at 1:06 PM, Guido van Rossum <guido at python.org> wrote:
On Tue, Oct 17, 2017 at 9:40 PM, Nick Coghlan <ncoghlan at gmail.com> wrote: [..]
By contrast, "contextvars.setctx" would need various wrappers to handle correctly reverting the context change, and would hence be prone to "changed the active context without changing it back" bugs (which can be especially fun when you're dealing with a shared pool of worker threads or processes).
So let's have both. The main reason why I don't like 'setctx()' is because it would make it harder for us to adopt PEP 550-like design later in the future (if we need that.) PEP 550 is designed in such a way, that 'generator.send()' is the only thing that can control the actual stack of LCs. If users can call 'setctx' themselves, it means that it's no longer safe for 'generator.send()' to simply pop the topmost LC from the stack.
I don't see why this is a concern -- Python is a "consenting adults" language. If users decide to start mucking around with advanced behavior and something breaks, well, they own all the pieces! ;)
Unless it's extremely difficult to not seg-fault in such a situation I don't think this is a valid argument.
--
Ethan
- Previous message (by thread): [Python-Dev] Timeout for PEP 550 / Execution Context discussion
- Next message (by thread): [Python-Dev] Timeout for PEP 550 / Execution Context discussion
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]