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

Formatting around "and" #40

Open
grantjenks opened this issue Feb 12, 2021 · 4 comments
Open

Formatting around "and" #40

grantjenks opened this issue Feb 12, 2021 · 4 comments

Comments

@grantjenks
Copy link
Owner

I'm not thrilled with this diff:

     def __eq__(self, that):
         if not isinstance(that, type(self)):
             return NotImplemented
-        return (self.__slots__ == that.__slots__
-                and all(item == iota for item, iota in zip(self, that)))
+        return self.__slots__ == that.__slots__ and all(
+            item == iota for item, iota in zip(self, that)
+        )
 
     def __repr__(self):
@grantjenks
Copy link
Owner Author

I think the ideal here is:

     def __eq__(self, that):
         if not isinstance(that, type(self)):
             return NotImplemented
         return (
            self.__slots__ == that.__slots__
            and all(item == iota for item, iota in zip(self, that))
        )

@wbolster
Copy link

oh hai,

imo, the ‘ideal’ is far from ideal.

  • for starters, this code implicitly depends on the type being iterable.
  • on top of that, it implicitly assumes that iteration yields the values worth comparing, which may or may not be the same as having equal values in each field defined in __slots__
  • the variable ‘that’ would contrast with a variable ‘this’, but this is python, which uses ‘self’. so ‘self’ / ‘other’ would be a better choice.
  • a variable named ‘iota’ means nothing
  • a variable ‘item’ compared to ‘iota’ doesn't mean much either

that said, here's a quick attempt that would be closer to ‘ideal’, and lo and behold, it doesn't suffer from perceived formatting ‘problems’ either:

class C:
    def __eq__(self, other):
        if not isinstance(other, type(self)):
            return NotImplemented

        if self.__slots__ != other.__slots__:
            return False

        for x in self.__slots__:
            if getattr(self, x) != getattr(other, x):
                return False

        return True

the ‘ideal’ solution would be to not write any code at all, and use attrs instead to declaratively define attributes and whether they should be included in an an equality comparison.

@merwok
Copy link

merwok commented Jul 20, 2022

This ticket is not a discussion of that __eq__ method, but of the formatting of specific lines by the black tool.

@wbolster
Copy link

which is way more subtle and complex than this ticket seems to imply; see psf/black#2156 (comment)

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

No branches or pull requests

3 participants