<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div>On Jan 3, 2018, at 12:26 PM, Victor Stinner <<a href="mailto:victor.stinner@gmail.com">victor.stinner@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="auto"><div class="gmail_extra" dir="auto"><div class="gmail_quote">Le 3 janv. 2018 06:05, "Yury Selivanov" <<a href="mailto:yselivanov.ml@gmail.com">yselivanov.ml@gmail.com</a>> a écrit :<blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div dir="auto">tuples in Python are immutable, but you can have a tuple with a dict as its single element. The tuple is immutable, the dict is mutable.</div><div dir="auto"><br></div><div dir="auto">At the C level we have APIs that can mutate a tuple though.</div><div dir="auto"><br></div><div dir="auto">Now, tuple is not a direct analogy to Context, but there are some parallels. Context is a container like tuple, with some additional APIs on top.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Sorry, I don't think that it's a good analogy. Context.run() is a public method accessible in Python which allows to modify the context. A tuple doesn't have such method.</div><div dir="auto"><br></div><div dir="auto">While it's technically possible to modify a tuple or a str at C level, it's a bad practice leading to complex bugs when it's not done carefully: see <a href="https://bugs.python.org/issue30156">https://bugs.python.org/issue30156</a> property_descr_get() optimization was fixed twice but still has a bug. I proposed a PR to remove the hack.</div><div dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div class="quoted-text"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><span style="font-family:sans-serif">Why Context could not inherit from MutableMapping? (Allow ctx.set(var, value) and ctx [var] = value.) Is it just to keep the API small: changes should only be made using var.set()?</span></div></div></blockquote><div dir="auto"><br></div></div><div dir="auto">Because that would be confusing to end users.</div><div dir="auto"><br></div><div dir="auto"> ctx = copy_context()</div><div dir="auto"> ctx[var] = something</div><div dir="auto"><br></div><div dir="auto">What did we just do? Did we modify the 'var' in the code that is currently executing? No, you still need to call Context.run to see the new value for var.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">IMHO it's easy to understand that modifying a *copy* of the current context doesn't impact the current context. It's one the first thing to learn when learning Python:</div><div dir="auto"><br></div><div dir="auto">a = [1, 2]</div><div dir="auto">b = a.copy()</div><div dir="auto">b.append(3)</div><div dir="auto"><span style="font-family:sans-serif">assert a == [1, 2]</span><br></div><div dir="auto"><span style="font-family:sans-serif">assert b == [1, 2, 3]</span></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div class="gmail_extra" dir="auto"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div dir="auto">Another problem is that MutableMapping defines a __delitem__ method, which i don't want the Context to implement.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I wouldn't be shocked if "del ctx [var]" would raise an exception.</div><div dir="auto"><br></div><div dir="auto">I almost never use del anyway. I prefer to assign a variable to None, since "del var" looks like C++ destructor whereas it's more complex than a direct call to the destructor.</div><div dir="auto"><br></div><div dir="auto">But it's annoying to have to call a function with Context.run() whereas context is just a mutable mapping. It seems overkill to me to have to call run() to modify a context variable:</div></div></div></blockquote><div><br></div><div>Do you have any use case for modifying a variable inside some context?</div><div><br></div><div>numpy, decimal, or some sort of tracing for http requests or async frameworks like asyncio do not need that.</div><br><blockquote type="cite"><div><div dir="auto"><div dir="auto"> run() changes temporarely the context and requires to use the indirect ContextVar API, while I know that ContextVar.set() modifies the context.</div><div dir="auto"><br></div><div dir="auto">Except of del corner case, I don't see any technical reason to prevent direct modification of a context.</div><div dir="auto"><br></div><div dir="auto">contextvars isn't new, it extends what we already have: decimal context. And decimal quick start documentation shows how to modify a context and then set it as the current context:</div><div dir="auto"><br></div></div></div></blockquote><div><br></div><div>I think you are confusing context in decimal and pep 567.</div><div><br></div><div>Decimal context is a mutable object. We use threading.local to store it. With pep 567 you will use a context variable behind the scenes to store it.</div><div><br></div><div>I think it's incorrect to compare decimal contexts to pep567 in any way.</div><div><br></div><div>Yury</div><br><blockquote type="cite"><div><div dir="auto"><div dir="auto"><div dir="auto">>>> myothercontext = Context(prec=60, rounding=ROUND_HALF_DOWN)</div><div dir="auto">>>> setcontext(myothercontext)</div><div dir="auto">>>> Decimal(1) / Decimal(7)</div><div dir="auto">Decimal('0.142857142857142857142857142857142857142857142857142857142857')</div><div dir="auto"><br></div></div><div dir="auto"><a href="https://docs.python.org/dev/library/decimal.html">https://docs.python.org/dev/library/decimal.html</a><br></div><div dir="auto"><br></div><div dir="auto"><div dir="auto" style="font-family:sans-serif">Well, technically it doesn't modify a context. An example closer to contextvars would be:</div><br></div><div dir="auto"><div dir="auto" style="font-family:sans-serif">>>> mycontext = getcontext().copy()</div><div dir="auto" style="font-family:sans-serif">>>> mycontext.prec = 60</div><div dir="auto" style="font-family:sans-serif">>>> setcontext(mycontext)</div><div dir="auto" style="font-family:sans-serif">>>> Decimal(1) / Decimal(7)</div><div dir="auto" style="font-family:sans-serif">Decimal('0.142857142857142857142857142857142857142857142857142857142857')</div><br></div><div dir="auto">Note: "getcontext().prec = 6" does modify the decimal context directly, and it's the *first* example in the doc. But here contextvars is different since there is no API to get the current API. The lack of API to access directly the current contextvars context is the main difference with decimal context, and I'm fine with that.</div><div dir="auto"><br></div><div dir="auto">It's easy to see a parallel since decimal context can be copied using Context.copy(), it has also multiple (builtin) "variables", it's just that the API is different (decimal context variables are modified as attributes), and i<span style="font-family:sans-serif">t's possible to set a context using decimal.setcontext().</span></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">Victor</span></div></div>
</div></blockquote></body></html>