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

Function smembers returns deepcopy #202

Merged
merged 4 commits into from
Aug 17, 2018
Merged

Function smembers returns deepcopy #202

merged 4 commits into from
Aug 17, 2018

Conversation

lowitea
Copy link

@lowitea lowitea commented Aug 12, 2018

No description provided.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 98.481% when pulling 720671d on lowitea:master into b354e47 on jamesls:master.

@coveralls
Copy link

coveralls commented Aug 12, 2018

Coverage Status

Coverage remained the same at 98.481% when pulling 2b02f98 on lowitea:master into b354e47 on jamesls:master.

Copy link
Collaborator

@bmerry bmerry left a comment

Choose a reason for hiding this comment

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

Good catch. Can you rather use the .copy method on the set, for consistency with other places in the code that need to copy the set (the set contains immutable objects, so a deep copy isn't necessary). Can you also add a unit test to catch the original bug.

@lowitea
Copy link
Author

lowitea commented Aug 16, 2018

@bmerry done

@bmerry
Copy link
Collaborator

bmerry commented Aug 17, 2018

I think that's not the best way to test this. As far as I'm aware Python doesn't guarantee that mutating a sequence while iterating over it will lead to an exception, and even if it did, it's an indirect way of testing that the value returned by smembers is not affected by future redis operations on the set. A more direct test would be to

  1. Add some items to a set with sadd
  2. Get the set with smembers and store it in a variable
  3. Add some more items to the set
  4. Check that the set stored in the variable did not change.

@lowitea
Copy link
Author

lowitea commented Aug 17, 2018

@bmerry It's done. The old test is also left. This is the real situation that has arisen in me.

@bmerry
Copy link
Collaborator

bmerry commented Aug 17, 2018

Thanks.

@@ -1488,6 +1488,12 @@ def test_sismember_wrong_type(self):
def test_smembers(self):
self.assertEqual(self.redis.smembers('foo'), set())

def test_smembers_copy(self):
self.redis.sadd('foo', 'member1')
set = self.redis.smembers('foo')
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you call this something other than set, since that's a builtin type.

self.redis.sadd('foo', 'member1')
set = self.redis.smembers('foo')
self.redis.sadd('foo', 'member2')
self.assertNotEqual(set, self.redis.smembers('foo'))
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe rather check that self.assertEqual(value, set(['member1'])) since that's a more specific test.

@bmerry bmerry merged commit cb10fbe into jamesls:master Aug 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants