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

gh-94808: add tests covering PySequence_[InPlace]Concat #99319

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

sobolevn
Copy link
Member

@sobolevn sobolevn commented Nov 10, 2022

Key points:

  1. I've covered these two C-API function calls by covering operator module, which uses these functions in their C implementation. I think that this is better because it also tests a lot of other things, not just a single API function.
  2. I've followed the module style: it has big tests cases for operators, this is why I didn't bother creating a new spec or separate test cases for each sub-case

@sobolevn
Copy link
Member Author

There's an unrelated test failure:

PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'D:\a\1\b\test\test_python_3768�\test_python_worker_5520�'

@sobolevn sobolevn closed this Nov 13, 2022
@sobolevn sobolevn reopened this Nov 13, 2022
Copy link
Contributor

@kumaraditya303 kumaraditya303 left a comment

Choose a reason for hiding this comment

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

Looks great!

@kumaraditya303
Copy link
Contributor

cc @gvanrossum

Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

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

Let's first have a discussion about the appearance and intentions of these tests here.

Lib/test/test_operator.py Outdated Show resolved Hide resolved
Comment on lines 538 to 542
self.assertEqual(operator.concat(data1, data2),
ListSubclass([1, 2, 'a', 'b']))
self.assertEqual(operator.concat(data1, data2), data1 + data2)
self.assertEqual(data1, ListSubclass([1, 2])) # must not change
self.assertEqual(data2, ListSubclass(['a', 'b'])) # must not change
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't prove much. The results are in all cases list instances, not ListSubclass instances, because of the way list operator overloading works -- data1+data2 is a plain list, and __eq__ considers a plain list equal to a list subclass with the same elements. The test makes it appear differently.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good catch, thanks! I've totally missed that. I've added several assertIsInstance checks and updated the expected values.

Lib/test/test_operator.py Outdated Show resolved Hide resolved
Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

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

Sorry, I still have some quibbles.

self.assertEqual(operator.concat(data1, data2), data1 + data2)

res = operator.concat(data1, data2)
self.assertIsInstance(res, list)
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't prove anything, does it? Whether the result is a ListSubclass or a plain list, this will always be true. If you want to say something interesting here I'd assert that it isn't a ListSubclass instance.

res = operator.concat(data1, data2)
self.assertIsInstance(res, list)
self.assertEqual(res, [1, 2, 'a', 'b'])
self.assertIsInstance(data1, ListSubclass)
Copy link
Member

Choose a reason for hiding this comment

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

I don't see the point of this -- of course data1 and data2 are instances of ListSubclass, that's how they were created.

TupleSubclass(['a', 'b', 1, 2]))
self.assertEqual(operator.concat(data1, data2), data1 + data2)
res = operator.concat(data1, data2)
self.assertIsInstance(res, TupleSubclass)
Copy link
Member

Choose a reason for hiding this comment

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

This one is good.

res = operator.concat(data1, data2)
self.assertIsInstance(res, TupleSubclass)
self.assertEqual(res, TupleSubclass(['a', 'b', 1, 2]))
self.assertIsInstance(data1, TupleSubclass)
Copy link
Member

Choose a reason for hiding this comment

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

But this is still questionable. I can't think of a scenario where this would fail.

Or do you have coverage results showing this is needed? (Where?)

Ditto for data2 and again in the following block of tests.

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@sobolevn
Copy link
Member Author

Sorry, it took me quite longer than I expected to get back to it :)

I've addressed your main review points. I went with very defensive asserts in this case.
I agree that most of them do not make much sense.

So, I've made several changes to this PR:

  1. I've added more cases for subtypes to cover all combinations: subtype + subtype, subtype + parent, parent + subtype. It does not really affect coverage, but it feels like a right thing to do
  2. I've remove all type assertions except: results, arguments that do mutate (iconcat and list)
  3. I've changed type assertions for tuple and list to be exact, for example: self.assertIs(type(res), tuple)

So, I hope it should be good now!
Thanks again for the review, it helped a lot!

@sobolevn
Copy link
Member Author

I have made the requested changes; please review again

@bedevere-bot
Copy link

Thanks for making the requested changes!

@kumaraditya303, @gvanrossum: please review the changes made to this pull request.

@gvanrossum
Copy link
Member

Please find another reviewer, I'm on vacation.

@sobolevn
Copy link
Member Author

Happy vacation 🏖️ 😊

@kumaraditya303 kumaraditya303 removed their request for review July 8, 2023 08:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants