Showing content from http://mail.python.org/pipermail/python-dev/attachments/20170828/151e671d/attachment.html below:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#330033" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 8/28/2017 6:50 PM, Guido van Rossum
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAP7+vJ+EQrdaD3qCX3BUWoj88-Kj7h6w+h8_u+ZS+GiEqEvDeA@mail.gmail.com">FWIW
we *could* have a policy that OS threads also inherit the lookup
chain from their creator, but I doubt that's going to fly with
backwards compatibility.</blockquote>
<br>
Since LC is new, how could such a policy affect backwards
compatibility?<br>
<br>
The obvious answer would be that some use cases that presently use
other mechanisms that "should" be ported to using LC would have to
be careful in how they do the port, but discussion seems to indicate
that they would have to be careful in how they do the port anyway.<br>
<br>
One of the most common examples is the decimal context. IIUC, each
thread gets its initial decimal context from a global template,
rather than inheriting from its parent thread. Porting decimal
context to LC then, in the event of OS threads inheriting the lookup
chain from their creator, would take extra work for compatibility:
setting the decimal context from the global template (a step it must
already take) rather than accepting the inheritance. It might be
appropriate that an updated version of decimal that uses LC would
offer the option of inheriting the decimal context from the parent
thread, or using the global template, as an enhancement.<br>
<br>
</body>
</html>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4