2016-12-17 18:35 GMT+09:00 Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp>:

I don't understand this.  I assume that there are no such platforms
supported at present.  I would think that when such a platform becomes
supported, code supporting "key" functions becomes unsupportable
without #ifdefs on that platform, at least directly.  So you should
either (1) raise UnimplementedError, or (2) provide the API as a
wrapper over the new API by making the integer keys indexes into a
table of TSS'es, or some such device.  I don't understand how (3)
"make it a no-op" can be implemented for PyThread_create_key -- return
0 or -1?  That would only work if there's a failure return status like
0 or -1, and it seems really dangerous to me since in general a lot of
code doesn't check status even though it should.  Even for code
checking the status, the error message will be suboptimal ("creation
failed" vs. "unimplemented").

PyThread_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 PyThread_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.

(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 TLS 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.

Kind regards,
Masayuki