Regression: S3 UPaths are no longer hashable

[johnnyg]

Python v3.11

version 0.1.4 of upath:

>> hash(UPath("s3://bucket/file"))
9171179727552408191

version 0.2.0 of upath:

>> hash(UPath("s3://bucket/file"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/user/mamba/envs/dev/lib/python3.11/site-packages/upath/core.py", line 574, in __hash__
    return hash((self.path, self.storage_options, self.protocol))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: unhashable type: 'mappingproxy'

[ap--]

Hey @johnnyg

Thank you for reporting! That's definitely a bug. I'll try to get a out a fixed version on the weekend.

Could you describe your use case for hashable UPath instances?
Are you using them as keys in a mapping to associate other data to the instance?

Note:

In v0.1.4 __hash__ was using pathlib's implementation, which means it just relied on .parts (or ._cparts). So while UPath instances are hashable in v0.1.x, it might not be the hash you want.

>>> import upath  # universal_pathlib==0.1.4
>>> hash(upath.UPath("s3://bucket/file.txt"))
-4817263177334106539
>>> hash(upath.UPath("memory:///file.txt"))
-4817263177334106539

Cheers,
Andreas

[johnnyg]

Hi @ap--

Thanks for your response!

Yeah the current use case is using it in a dict so we can associate it with other data but also using @cache on a function which has a UPath as a parameter.

Good to know about the current hash implementation; in the mapping scenario this won't be a problem as the paths will always have the same protocol but this could be an issue when they're used in the memoization as that function will get a mix of protocols that may have the same path.