TYPES: add types in core.util.hashing #28916
Conversation
pandas/core/util/hashing.py
Outdated
| @@ -26,13 +26,17 @@ | |||
| _default_hash_key = "0123456789123456" | |||
|
|
|||
|
|
|||
| def _combine_hash_arrays(arrays, num_items: int): | |||
| def _combine_hash_arrays(arrays, num_items: int) -> np.uint64: | |||
There was a problem hiding this comment.
for now, I think we are going to type using python int. xref #28843 (comment)
originally, I assumed that since a numpy int is not an instance of python int, that it needed to be treated differently. But since mypy is a static type checker and has no knowledge of the actual value then a python int should be compatible with a numpy int for type checking purposes.
Also, without numpy stubs np.uint64 will be resolving to Any. so this is not adding any value as far as type checking is concerned, but granted does add value from a documentation perspective.
| @@ -58,7 +62,7 @@ def hash_pandas_object( | |||
| obj, | |||
| index: bool = True, | |||
| encoding: str = "utf8", | |||
| hash_key=None, | |||
| hash_key: str = _default_hash_key, | |||
There was a problem hiding this comment.
can you remove L91 and L92?
|
@simonjayhawkins changing np.uint64 to int caused mypy to complain. any other suggestions? |
|
Shouldn't the return type of |
I think you're right, yes. Will update. I look forward to the day when annotations support cython-like |
|
Closing for now to clear the queue, will troubleshoot locally. |
cc @simonjayhawkins