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
New post: Django Q objects with py3 and pytest #7
Conversation
@yanneves Can I get a merge? |
Nice! |
* `left` and `right` are not considered equal. | ||
""" | ||
assert type(left) is Q | ||
assert type(right) is Q |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
assert isinstance(left, Q) and isinstance(right, Q)
??
https://stackoverflow.com/questions/1549801/differences-between-isinstance-and-type-in-python
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did look at using isinstance
and made the decision purely on the output that pytest gives:
================================= FAILURES =================================
________________________________ test_fails ________________________________
test_assert_q_equal.py:112: in test_fails
assert isinstance(a, Q)
E AssertionError: assert False
E + where False = isinstance('Q', Q)
_______________________________ test_fails2 ________________________________
test_assert_q_equal.py:116: in test_fails2
assert type(a) is Q
E AssertionError: assert <class 'str'> is Q
E + where <class 'str'> = type('Q')
==================== 2 failed, 8 passed in 0.07 seconds ====================
Using type
means that pytest explains what the type was that was found in the output and I found this more helpful.
Do you think I should abandon that idea and go for isinstance
for the flexibility?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well you could just assert isinstance(a, Q), f'{a.__class__} is not subclass of Q'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a much better idea than either of mine! I'll try it out and PR it in.
Django's Q object does not implement ``__cmp__`` and neither does | ||
``Node`` which it extends (``Node`` is in the ``django.utils.tree`` module). | ||
|
||
Unfortunately, that means that comparison of Q objects that are equal fails. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you know, django does accept PR's
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My guess would be that do to this well could take quite a large amount of effort while the payoff would be small. In the original post I wrote about why I thought this would not be implemented in Django: http://jamescooke.info/comparing-django-q-objects.html#the-perfect-world-predicate-logic
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could always argue that cmp
could be done with str(self) == str(other)
as a basic workaround like you have here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds like an idea - I might give it a go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went and added my comment as a review like a GitHub n00b.
Django's Q object does not implement ``__cmp__`` and neither does | ||
``Node`` which it extends (``Node`` is in the ``django.utils.tree`` module). | ||
|
||
Unfortunately, that means that comparison of Q objects that are equal fails. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My guess would be that do to this well could take quite a large amount of effort while the payoff would be small. In the original post I wrote about why I thought this would not be implemented in Django: http://jamescooke.info/comparing-django-q-objects.html#the-perfect-world-predicate-logic
What do you think?
@yanneves Thanks for reading. @adamchainz Thanks for reviewing. I'm going to merge and publish but I'll update the post based on your comments Adam |
Fixes #6
Adds new post comparing Q objects in Python 3 and links the two posts.