On Sun, Dec 18, 2016 at 12:10 AM, Masayuki YAMAMOTO <ma3yuki.8mam...@gmail.com> wrote: > 2016-12-17 18:35 GMT+09:00 Stephen J. Turnbull > <turnbull.stephen...@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.
Yep--I think it speaks to the sensibleness of that decision that I pretty much read your mind :) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/