Is it correct that strings, bytes objects, bytearrays, floats, fractions, decimals can be coerced to an interpreter ID?

>>> import _xxsubinterpreters as interpreters
>>> id = interpreters.InterpreterID('10', force=True)
>>> id == 10
True
>>> id == 10.1
True
>>> id == '1_0'
True
>>> id == bytearray(b'10')
True

Should not the constructor accept only ints and int-like objects and the comparison return True only for integer numbers?

There are other bugs here: raising OverflowError on comparison with large numbers and silencing all errors in some circumstances that can lead to returning a wrong result when errors like KeyboardInterrupt, RecursionError, MemoryError are occurred.

Urk! Having `10 == id == 10.1` should imply `10 == 10.1`, by transitivity.

Are interpreter.InterpreterID objects hashable? If so, we've got a violation of the rule that `x == y` implies `hash(x) == hash(y)`.

PR 15652 fixes some bugs. But I am not sure that floats and strings (and bytearrays, and fractions) should be accepted in constructors and several other functions. Although there was a test for strings. What is a use case? Should not an ID be an integer?

Regardless of the intention of the _xx... author, intransitive equality is objectionable as it violates the assumption of sets and dicts.  We went through this before with decimal.Decimal when the original implementation had 1.0 == 1 == Decimal(1) but 1.0 != Decimal(1).  The latter was fixed.  Here, I think the fix should be to not make the id be equal to everything it can be derived from.

I have doubts about accepting floats and bytes objects in all function that accept InterpreterID or ChannelID. Is it intentional? There are tests for strings.

There is more serious issue: InterpreterID and ChannelID are declared as int subclasses, but actually they have incompatible structure, so using them as int causes a crash. For example, the following code is crashed:

    float(int(id)) == id

New changeset bf169915ecdd42329726104278eb723a7dda2736 by Serhiy Storchaka in branch 'master':
bpo-38005: Fixed comparing and creating of InterpreterID and ChannelID. (GH-15652)
https://github.com/python/cpython/commit/bf169915ecdd42329726104278eb723a7dda2736

New changeset f37a9831027ecfe948697cdb5e35b417805d94e5 by Serhiy Storchaka in branch '3.8':
[3.8] bpo-38005: Fixed comparing and creating of InterpreterID and ChannelID. (GH-15652) (GH-16145)
https://github.com/python/cpython/commit/f37a9831027ecfe948697cdb5e35b417805d94e5

I would remove also converting a string to InterpreterID. The code would be simpler without it. I left it because there was explicit tests for it, but what is a use case for InterpreterID(string)?

Yeah, dropping str support is fine.  It wouldn't be hard to add it back in if later we find it's useful. :)

New changeset 543a3951a1c96bae0ea839eacec71d3b1a563a10 by Serhiy Storchaka in branch 'master':
bpo-38005: Remove support of string argument in InterpreterID(). (GH-16227)
https://github.com/python/cpython/commit/543a3951a1c96bae0ea839eacec71d3b1a563a10

New changeset ca14f047b068cd0fb81ef3d5e7bea19fe8af1b58 by Miss Islington (bot) in branch '3.8':
bpo-38005: Remove support of string argument in InterpreterID(). (GH-16227)
https://github.com/python/cpython/commit/ca14f047b068cd0fb81ef3d5e7bea19fe8af1b58