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

New post: Django Q objects with py3 and pytest #7

Merged
merged 3 commits into from May 31, 2017

Conversation

jamescooke
Copy link
Owner

Fixes #6

Adds new post comparing Q objects in Python 3 and links the two posts.

@jamescooke
Copy link
Owner Author

@yanneves Can I get a merge?

@yanneves
Copy link

Nice! .rst is a new syntax to me. Looks good to merge.

* `left` and `right` are not considered equal.
"""
assert type(left) is Q
assert type(right) is Q
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Owner Author

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?

Copy link
Contributor

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'

Copy link
Owner Author

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.
Copy link
Contributor

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

Copy link
Owner Author

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?

Copy link
Contributor

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

Copy link
Owner Author

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 👍

Copy link
Owner Author

@jamescooke jamescooke left a 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.
Copy link
Owner Author

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?

@jamescooke
Copy link
Owner Author

@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 😄

@jamescooke jamescooke merged commit efe7929 into master May 31, 2017
@jamescooke jamescooke deleted the django-q-obj-py-3 branch May 31, 2017
@jamescooke jamescooke mentioned this pull request Jun 4, 2017
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.

None yet

3 participants