Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

packages: make hash() consistent and incl features #370

Merged
merged 4 commits into from
May 26, 2022

Conversation

abn
Copy link
Member

@abn abn commented May 24, 2022

No description provided.

@abn abn requested a review from a team May 24, 2022 18:03
src/poetry/core/packages/specification.py Show resolved Hide resolved
src/poetry/core/packages/package.py Outdated Show resolved Hide resolved
src/poetry/core/packages/package.py Show resolved Hide resolved
dimbleby added a commit to dimbleby/poetry that referenced this pull request May 25, 2022
@radoering
Copy link
Member

Just a quick thought when deciding what to put into the hash for each class. In my understanding, it's not required to consider each attribute in the hash even if it is considered for equality. E.g., consider the following slightly exaggerated example:

class A:
    def __init__(self, a):
        self.a = a

    def __hash__(self):
        return 0

    def __eq__(self, other):
        return self.a == other.a

    def __repr__(self):
        return f'A({self.a})'


s = {A(0), A(1), A(2)}
print(s)

Output: {A(0), A(1), A(2)}

It might be inperformant, but it seems to be valid even though every instance has the same hash.

Thus, I tend to say we have to decide for each attribute:

  • relevant for equality? if yes -> use in __eq__
  • if used in __eq__, also immutable? if yes -> use in __hash__

In other words, two (simplified) rules that must not be broken:

  • attributes used in __hash__ must be used in __eq__
  • attributes used in __hash__ must be immutable

@abn
Copy link
Member Author

abn commented May 25, 2022

Split out the attribute change to #375

@radoering radoering marked this pull request as ready for review May 26, 2022 15:36
@radoering radoering dismissed their stale review May 26, 2022 16:05

Resolved by myself. ;)

@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

Copy link
Member Author

@abn abn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good to me. Someone else might need to approve.

@abn abn merged commit a5af3b8 into python-poetry:main May 26, 2022
@abn abn deleted the fix-package-hash branch May 26, 2022 16:41
@radoering radoering mentioned this pull request May 29, 2022
2 tasks
@radoering radoering mentioned this pull request Jul 9, 2022
maksbotan added a commit to maksbotan/poetry-core that referenced this pull request Aug 7, 2022
yggi49 added a commit to yggi49/poetry-core that referenced this pull request Nov 12, 2022
Instead of relying on regular expressions, this patch leverages Python’s
builtin `email.utils.parseaddr()` functionality to parse an RFC-822-compliant
email address string into its name and address parts.

This should also resolve issues with special characters in the name
part; see for example Poetry issues python-poetry#370 and python-poetry#798.

python-poetry/poetry#370
python-poetry/poetry#798
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants