Ensure audb.Repository is hashable

[hagenw]

As audb.config.REPOSITORIES is given as a list of repositories, one would expect set(audb.config.REPOSITORIES) to work as well, which is not the case at the moment. It is solved in this pull request by adding a __hash__() method to audb.Repository.

Summary by Sourcery

Make audb.Repository hashable by implementing the hash method and add a test to ensure its hashability.

Enhancements:

• Add hash method to audb.Repository to make it hashable.

Tests:

• Add test to verify that audb.Repository objects are hashable.

[sourcery-ai]

Reviewer's Guide by Sourcery

The PR implements hashability for the audb.Repository class by adding a __hash__() method that uses the string representation of the repository as the basis for hash calculation. This change allows Repository objects to be used in sets and as dictionary keys.

Class diagram for audb.Repository with hashability

classDiagram
    class Repository {
        +__eq__(other) bool
        +__hash__() int
        +__repr__() str
    }
    note for Repository "Added __hash__ method to enable hashability"

Loading

File-Level Changes

Change	Details	Files
Added hashability to Repository class	Implemented hash() method that returns hash of repository's string representation Added test to verify Repository objects are hashable Added test to verify Repository objects work in sets	audb/core/repository.py tests/test_repository.py

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time. You can also use
  this command to specify where the summary should be inserted.

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey @hagenw - I've reviewed your changes - here's some feedback:

Overall Comments:

• The test case comparing set([repository]) to set([str(repository)]) is incorrect - these will never be equal since they contain different types. Consider testing set operations with Repository objects instead, e.g. set([repository]) == set([repository])

Here's what I looked at during the review

• 🟢 General issues: all looks good
• 🟢 Security: all looks good
• 🟡 Testing: 1 issue found
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[ChristianGeng]

I have one question:

when reading the code, I thought that you actually are about to implement __eq__.
I don't know what the default implementation of __eq__ is, but this post suggests that
it is ==.

Would it then not make sense to use __hash__ to calculate __eq__ in the same issue?

[hagenw]

__eq__() was implemented before, and we use return str(self) == str(other). So, I guess your concern is that it should not be independent from __bash__() and we should better update it to return hash(self) == hash(other), correct?

[ChristianGeng]

__eq__() was implemented before, and we use return str(self) == str(other). So, I guess your concern is that it should not be independent from __bash__() and we should better update it to return hash(self) == hash(other), correct?

Ah so __eq__() exists. This makes it harder for me to comment as I do not know where the old implementation of __eq__ has been important and used in the past.

__str__ would get its value itself via __repr__, and __repr__ contains all necessary information (name, host, backend) to identify a repo. So I would not expect this to be of crucial importance any more.

Conceptually it was more intuitive to me to have return hash(self) == hash(other) when reading the code in the first place. But on the other hand it wouldn't buy much (and so I cannot see the need). So I am happy and will close with this comment.

I close the issue not the thread. Reopening.

[ChristianGeng]

Sorry I closed the MR and not the thread. Reopened.

[hagenw]

As you are ok with __eq__ is this fine to merge, or are there other things you might want to discuss?

[ChristianGeng]

As you are ok with __eq__ is this fine to merge, or are there other things you might want to discuss?

Yes, using __repr__ to create equality here is fine. Equality is then module wise. Dependencies uses DataFrame equality to implement __eq__.