This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author yselivanov
Recipients gvanrossum, mark.dickinson, methane, ned.deily, skrah, vstinner, yselivanov
Date 2018-01-27.18:46:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1517078763.12.0.467229070634.issue32630@psf.upfronthosting.co.za>
In-reply-to
Content
Thank you, Stefan.  I've updated the PR with an asyncio+decimal test and run tests in refleak mode to make sure there's no regression there.

If during the beta/rc period we see that contextvars isn't stable enough or something I'll revert this change before 3.7.0 myself, so that decimal users will not be disturbed.

I'll merge the PR once the CI is green.

> Yes, that's the big question. In the generator discussions people were advised to use "with" whenever possible, so I assume short blocks *will* be used.

Yes, I used decimal examples all the time to showcase how context is supposed to work with generators.  Most of those examples were specifically constructed to illustrate some point, but I don't think that real-world code uses a 'with localcontext()' statement in every function.

Unfortunately there's no way (at least known to me) to make 'ContextVar.set()' faster than it is now.  I use HAMT which guarantees that all set operations will have O(log n) performance; the other known approach is to use copy-on-write (as in .NET), but that has an O(n) ContextVar.set() performance.  So I guess a slightly slower 'with localcontext()' is the price to pay to make decimal easier to use for async/await code.
History
Date User Action Args
2018-01-27 18:46:03yselivanovsetrecipients: + yselivanov, gvanrossum, mark.dickinson, vstinner, ned.deily, methane, skrah
2018-01-27 18:46:03yselivanovsetmessageid: <1517078763.12.0.467229070634.issue32630@psf.upfronthosting.co.za>
2018-01-27 18:46:03yselivanovlinkissue32630 messages
2018-01-27 18:46:03yselivanovcreate