<div dir="ltr">2016-12-17 18:35 GMT+09:00 Stephen J. <span class="" style="" id=":2xk.1" tabindex="-1">Turnbull</span> <span dir="ltr"><<a href="mailto:turnbull.stephen.fw@u.tsukuba.ac.jp" target="_blank"><span class="" style="" id=":2xk.2" tabindex="-1">turnbull</span>.<span class="" style="" id=":2xk.3" tabindex="-1">stephen</span>.<span class="" style="" id=":2xk.4" tabindex="-1">fw</span>@u.<span class="" style="" id=":2xk.5" tabindex="-1">tsukuba</span>.ac.<span class="" style="" id=":2xk.6" tabindex="-1">jp</span></a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im gmail-HOEnZb">I don't understand this.  I assume that there are no such platforms</span><br><span class="gmail-im gmail-HOEnZb">
supported at present.  I would think that when such a platform becomes</span><br><span class="gmail-im gmail-HOEnZb">
supported, code supporting "key" functions becomes unsupportable</span><br><span class="gmail-im gmail-HOEnZb">
without #ifdefs on that platform, at least directly.  So you should</span><br><span class="gmail-im gmail-HOEnZb">
either (1) raise UnimplementedError, or (2) provide the API as a</span><br><span class="gmail-im gmail-HOEnZb">
wrapper over the new API by making the integer keys indexes into a</span><br><span class="gmail-im gmail-HOEnZb">
table of TSS'es, or some such device.  I don't understand how (3)</span><br><span class="gmail-im gmail-HOEnZb">
"make it a no-op" can be implemented for PyThread_create_key -- return</span><br><span class="gmail-im gmail-HOEnZb">
0 or -1?  That would only work if there's a failure return status like</span><br><span class="gmail-im gmail-HOEnZb">
0 or -1, and it seems really dangerous to me since in general a lot of</span><br><span class="gmail-im gmail-HOEnZb">
code doesn't check status even though it should.  Even for code</span><br><span class="gmail-im gmail-HOEnZb">
checking the status, the error message will be suboptimal ("creation</span><br><span class="gmail-im gmail-HOEnZb">
failed" vs. "unimplemented").</span></blockquote><div> </div><span class="" style="" id=":2xk.7" tabindex="-1">PyThread</span>_create_key has required user to check the return value since when key creation fails, returns -1 instead of valid key value.  Therefore, my patch changes <span class="" style="" id=":2xk.8" tabindex="-1">PyThread</span>_create_key that always return -1 on platforms that cannot cast key to int safely and current API never return valid key value to these platforms.  Its advantage to not change function specifications and no effect on supported platforms. Hence, this is reason that doesn't raise any exception on the API.<br><br>(2) of ideas can enable current API on specific-platforms. If it's simple, I'd have liked to select it.  However, work that brings current API using native <span class="" style="" id=":2xk.9" tabindex="-1">TLS</span> to specific-platforms brings duplication implementation that manages keys, and it's ugly (same reason for Erik's draft, the last item of Rejected Ideas).  Thus, I gave up to keep feature and decided to implement "no-op", delegate error handling to API users.<br><br>Kind regards,<br><span class="" style="" id=":2xk.10" tabindex="-1">Masayuki</span></div>