GeezerVison is showing github.com — Consider restoring _PyHASH_INF/BITS/MODULUS/IMAG as public · Issue #111389 · python/cpython
Consider restoring _PyHASH_INF/BITS/MODULUS/IMAG as public #111389DescriptionThis is used to implement CPython-like hashing of numeric types e.g. in Sage or in gmpy2. Actually, the same info is available via sys.hash_info, so I don't see reasons to hide this in Python.h.
See #106320 and #107026.
Linked PRs
Activitysobolevn commented on Oct 27, 2023 vstinner commented on Oct 27, 2023 Python 3.12 has 5 constants implemented as macros:
_PyHASH_BITS_PyHASH_IMAG_PyHASH_INF_PyHASH_MODULUS_PyHASH_MULTIPLIER
Significant commits related to these constants:
- commit 985ecdc: new
Include/pyhash.h header file
- commit 27cbcd6: in
Include/pyport.h, use unsigned integer, replace Py_hash_t with Py_uhash_t
- commit 63e6c32: add
_PyHASH_MULTIPLIER constant
- commit 8035bc5: add
Py_uhash_t type, replace unsigned long with size_t
- commit dc787d2: add
_PyHASH_BITS, _PyHASH_IMAG, _PyHASH_INF and _PyHASH_MODULUS constants
the same info is available via sys.hash_info, so I don't see reasons to hide this in Python.h.
Right, it makes sense to make them public. I'm not sure why it was private before.
We can keep them as macros, but maybe we should consider declaring them as variables (using with dlsym for example) to make them usable in programming languages and use cases which cannot use macros. vstinner commented on Oct 27, 2023
We can keep them as macros, but maybe we should consider declaring them as variables (using with dlsym for example) to make them usable in programming languages and use cases which cannot use macros.
I created capi-workgroup/api-evolution#37 to discuss that. skirpichev commented on Oct 28, 2023 vstinner commented on Oct 28, 2023 Should we also add some functions like Py_HashPointer()? vstinner commented on Oct 28, 2023 @skirpichev:
are you about documenting these macroses somewhere (I propose https://docs.python.org/3/library/sys.html#sys.hash_info, where we could mention them in descriptions for different fields) AND about renaming them too (add PyUnstable_ aliases)?
If constants are made public, yes, they must be documented.
I don't think that PyUnstable prefix is needed, these constants seem stable. skirpichev commented on Oct 29, 2023
Should we also add some functions like Py_HashPointer()?
Maybe others (I don't know examples), but not this function. It's used currently in the gmpy2, but this could be replaced by PyBaseObject_Type.tp_hash. And this is a documented replacement:
|
if math.isnan(x): |
|
return object.__hash__(x) |
If constants are made public, yes, they must be documented.
Ok, I'll go with suggested above sys.hash_info. Let me know if you have in mind a better place to put the docs.
these constants seem stable
Yep. But can be removed in any minor release, as _PyHASH_NAN. vstinner commented on Oct 30, 2023 skirpichev commented on Nov 7, 2023
Should we also add some functions like Py_HashPointer()?
UPD:
The one drawback with the PyBaseObject_Type.tp_hash solution above is that there is no guarantee that this function does accept an arbitrary pointer (not only a pointer to some PyObject subclass). (In gmpy2 we pass mpfr_t: https://github.com/aleaxit/gmpy/blob/e002e2c28994f6c9edd411c1f1e09d0bbbbfca9b/src/gmpy2_hash.c#L122)
On one hand, this is unlikely to be changed. On another hand, this situation is not documented. Maybe it should? vstinner commented on Nov 15, 2023 I restored _PyHASH constants with PR #112115. vstinner commented on Nov 15, 2023
Should we also add some functions like Py_HashPointer()?
I proposed PR #112096 to add Py_HashPointer() function. vstinner commented on Mar 9, 2024
This is used to implement CPython-like hashing of numeric types e.g. in Sage or in gmpy2.
You can now propose changes for these projects to use the public names :-) I added the constants to pythoncapi-compat: python/pythoncapi-compat@7539c7f
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|