Nick Coghlan added the comment: The concern I have with using an unsigned value as the interpreter ID is that it's applying the "NULL means an error" idiom or the "false means an error" idiom to a non-pointer and non-boolean return type, whereas the common conventions for integer return values are:
* 0 = success in CLI return codes * non-negative = success in int-based C APIs If we were to use int_fast32_t for IDs instead, then any negative value can indicate an error, and the main interpreter could be given ID 0 to better align with the threading.Thread naming scheme. Whether we hit runtime error at 2 billion subinterpreters or 4 billion subinterpreters in a single process isn't likely to make much difference to anyone, but choosing an idiosyncratic error indicator will impact everyone that attempts to interact with the API. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29102> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
