This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients brett.cannon, eric.snow, grahamd, ncoghlan, serhiy.storchaka, steve.dower
Date 2016-12-31.03:58:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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.
Date User Action Args
2016-12-31 03:58:52ncoghlansetrecipients: + ncoghlan, brett.cannon, grahamd, eric.snow, serhiy.storchaka, steve.dower
2016-12-31 03:58:51ncoghlansetmessageid: <>
2016-12-31 03:58:51ncoghlanlinkissue29102 messages
2016-12-31 03:58:50ncoghlancreate