Skip to content

gh-135865: Use the walrus operator in deepcopy #135857

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

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

Conversation

SobhanMP
Copy link

@SobhanMP SobhanMP commented Jun 23, 2025

Hi, I think the walrus operator's raison d'être was to make code like this less nested. Apologies if you do not accept whitespace fixes.

@bedevere-app

This comment was marked as resolved.

@python-cla-bot
Copy link

python-cla-bot bot commented Jun 23, 2025

All commit authors signed the Contributor License Agreement.

CLA signed

@bedevere-app

This comment was marked as duplicate.

@SobhanMP SobhanMP changed the title gh-NNNNNN: Use the walrus operator in deepcopy Use the walrus operator in deepcopy Jun 23, 2025
@bedevere-app

This comment was marked as duplicate.

@abstractedfox
Copy link
Contributor

Precedent suggests it would be good to have an open issue for this even if it's just a refactor

@SobhanMP
Copy link
Author

Will do it tonight!

@SobhanMP SobhanMP changed the title Use the walrus operator in deepcopy gh-135865: Use the walrus operator in deepcopy Jun 23, 2025
Copy link
Member

@ZeroIntensity ZeroIntensity left a comment

Choose a reason for hiding this comment

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

We typically don't accept "cosmetic changes" (changes that just change styling or whatever), but I think this is a reasonable refactor. cc @serhiy-storchaka as the copy maintainer.

Copy link
Member

Choose a reason for hiding this comment

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

We don't need blurb entries for internal-only changes.

@ZeroIntensity ZeroIntensity added the type-refactor Code refactoring (with no changes in behavior) label Jun 24, 2025
@picnixz
Copy link
Member

picnixz commented Jun 24, 2025

I'm not very fond of the "sometimes is not None" check and sometimes falsey check but I'm not sure about it. For instance, if someone uses __deepcopy__ = False and we make a falsey check only, it will fallback to the next branch instead of branching to the if so it would be a change of behavior.

I think we should do an is not None check everytime becausye an explicit falsey attribute shouldn't be accepted (and we should raise an appropriate TypeError).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting review skip news type-refactor Code refactoring (with no changes in behavior)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants