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 <1483156731.95.0.768445516495.issue29102@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
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: <1483156731.95.0.768445516495.issue29102@psf.upfronthosting.co.za>
2016-12-31 03:58:51ncoghlanlinkissue29102 messages
2016-12-31 03:58:50ncoghlancreate