[Martin] > ... > I feel this is deeper: Should there be a guarantee that the type used > to represent <type 'integer'> is large enough to hold a void*, or not? The confusion over what you mean still persists for me. In the Python I use <wink>, there is no type that identifies itself as <type 'integer'>. There's a type that identifies itself as <type 'int'>, and another as <type 'long'>. When the Language Reference Manual uses the word "integer", it generally means the union of those two. It's certainly not intended that objects of <type 'int'> can always hold a casted void*. It certainly is intended that objects of <type 'long'> can always hold a casted void*. So it's intended that a Python integer be able to hold a casted void*, but "integer" doesn't take a stand on whether the concrete type is Python int or Python long. After int/long unification is complete, the distinction will be even more a case of academic irrelevance. > You seem to think that Python should make no such guarantee, Definitely yes, or definitely no, depending on what you mean by "integer". I explained what I mean above. > which would then indicate that three of the four failing tests are broken > (I'm uncertain about test_queue at the moment). It's easy to believe that tests have broken, since (a) AFAIK nobody runs the tests on Win64, and (b) Win64 may well be the only platform around where sizeof(void*) > sizeof(long) in C (meaning that a casted void* can't fit in a Python int -- although it can fit in a Python integer, and PyLong_FromVoidPtr already knows how to deal with this).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4