← 返回首页
gh-94808: add tests covering `PySequence_[InPlace]Concat` by sobolevn · Pull Request #99319 · python/cpython · GitHub
Skip to content

Navigation Menu

Toggle navigation
Sign in
Appearance settings
Search or jump to...

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted
Cancel Submit feedback

Saved searches

Use saved searches to filter your results more quickly

Cancel Create saved search
Appearance settings
Resetting focus

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

Open
sobolevn wants to merge 6 commits into
python:mainfrom
sobolevn:cover-sequence-concat
Open

gh-94808: add tests covering PySequence_[InPlace]Concat#99319
sobolevn wants to merge 6 commits into
python:mainfrom
sobolevn:cover-sequence-concat

Conversation

sobolevn commented Nov 10, 2022 •
edited by bedevere-bot
Loading

Copy link
Copy Markdown
Member

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

bedevere-bot mentioned this pull request Nov 10, 2022
Open
bedevere-bot added awaiting review tests Tests in the Lib/test dir labels Nov 10, 2022

sobolevn commented Nov 10, 2022

Copy link
Copy Markdown
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 closed this Nov 13, 2022
sobolevn reopened this Nov 13, 2022
kumaraditya303 approved these changes Nov 24, 2022
View reviewed changes

kumaraditya303 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

Looks great!

kumaraditya303 commented Nov 24, 2022

Copy link
Copy Markdown
Contributor

cc @gvanrossum

gvanrossum reviewed Nov 24, 2022
View reviewed changes

gvanrossum left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

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

Comment thread Lib/test/test_operator.py Outdated Show resolved Hide resolved
Comment thread Lib/test/test_operator.py Outdated
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

gvanrossum Nov 24, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

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.

sobolevn Nov 25, 2022

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

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

Comment thread Lib/test/test_operator.py Outdated Show resolved Hide resolved
gvanrossum requested changes Nov 29, 2022
View reviewed changes

gvanrossum left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

Sorry, I still have some quibbles.

Comment thread Lib/test/test_operator.py Outdated
self.assertEqual(operator.concat(data1, data2), data1 + data2)

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

gvanrossum Nov 29, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

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.

Comment thread Lib/test/test_operator.py Outdated
res = operator.concat(data1, data2)
self.assertIsInstance(res, list)
self.assertEqual(res, [1, 2, 'a', 'b'])
self.assertIsInstance(data1, ListSubclass)

gvanrossum Nov 29, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

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

Comment thread Lib/test/test_operator.py
TupleSubclass(['a', 'b', 1, 2]))
self.assertEqual(operator.concat(data1, data2), data1 + data2)
res = operator.concat(data1, data2)
self.assertIsInstance(res, TupleSubclass)

gvanrossum Nov 29, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

This one is good.

Comment thread Lib/test/test_operator.py Outdated
res = operator.concat(data1, data2)
self.assertIsInstance(res, TupleSubclass)
self.assertEqual(res, TupleSubclass(['a', 'b', 1, 2]))
self.assertIsInstance(data1, TupleSubclass)

gvanrossum Nov 29, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

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 commented Nov 29, 2022

Copy link
Copy Markdown

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 commented Mar 24, 2023

Copy link
Copy Markdown
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 commented Mar 24, 2023

Copy link
Copy Markdown
Member Author

I have made the requested changes; please review again

bedevere-bot commented Mar 24, 2023

Copy link
Copy Markdown

Thanks for making the requested changes!

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

gvanrossum commented Mar 24, 2023

Copy link
Copy Markdown
Member

Please find another reviewer, I'm on vacation.

sobolevn commented Mar 24, 2023

Copy link
Copy Markdown
Member Author

Happy vacation 🏖️ 😊

kumaraditya303 removed their request for review July 8, 2023 08:56

github-actions Bot commented Apr 11, 2026

Copy link
Copy Markdown

This PR is stale because it has been open for 30 days with no activity.

github-actions Bot added the stale Stale PR or inactive for long period of time. label Apr 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Show hidden characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

kumaraditya303 kumaraditya303 approved these changes
gvanrossum Awaiting requested review from gvanrossum

Assignees

No one assigned

Labels

awaiting change review skip news stale Stale PR or inactive for long period of time. tests Tests in the Lib/test dir

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

Footer

© 2026 GitHub, Inc.