Skip to content

[3.8] bpo-42536: GC track recycled tuples (GH-23623) #23652

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Dec 7, 2020
Merged

[3.8] bpo-42536: GC track recycled tuples (GH-23623) #23652

merged 1 commit into from
Dec 7, 2020

Conversation

brandtbucher
Copy link
Member

@brandtbucher brandtbucher commented Dec 5, 2020 •
edited by bedevere-bot
Loading

CC @pablogsal, just to make sure I'm doing the manual backport with cherry_picker correctly (automatic backporting failed).

Several built-in and standard library types now ensure that their internal result tuples are always tracked by the garbage collector:

  • collections.OrderedDict.items
  • dict.items
  • enumerate
  • functools.reduce
  • itertools.combinations
  • itertools.combinations_with_replacement
  • itertools.permutations
  • itertools.product
  • itertools.zip_longest
  • zip

Previously, they could have become untracked by a prior garbage collection.
(cherry picked from commit 226a012)

https://bugs.python.org/issue42536

@brandtbucher
bpo-42536: GC track recycled tuples (pythonGH-23623)
db2788a 
Several built-in and standard library types now ensure that their internal result tuples are always tracked by the garbage collector:

- collections.OrderedDict.items
- dict.items
- enumerate
- functools.reduce
- itertools.combinations
- itertools.combinations_with_replacement
- itertools.permutations
- itertools.product
- itertools.zip_longest
- zip

Previously, they could have become untracked by a prior garbage collection.
(cherry picked from commit 226a012)
@bedevere-bot bedevere-bot added the type-bug An unexpected behavior, bug, or error label Dec 5, 2020
@bedevere-bot bedevere-bot mentioned this pull request Dec 5, 2020
Merged
@brandtbucher
Copy link
Member Author

Not sure what's up with Travis. It looks like it's using an old (perhaps 3.5 system python?) python3 executable when running make -j4 regen-all:

python3 ./Tools/scripts/update_file.py ./Include/graminit.h ./Include/graminit.h.new
  File "./Tools/clinic/clinic.py", line 1772
    filename_new = f"{filename}.new"
                                   ^
SyntaxError: invalid syntax

@brandtbucher
Copy link
Member Author

I know Travis has been problematic in the past. I see this same failure on several other recent 3.8 backports as well, so I think it can safely be ignored here.

(I'll go ahead and open an issue for it, though.)

@brandtbucher
Copy link
Member Author

brandtbucher commented Dec 5, 2020 •
edited by bedevere-bot
Loading

(I'll go ahead and open an issue for it, though.)

bpo-42574

@pablogsal
Copy link
Member

so I think it can safely be ignored here.

Yeah, let's track that issue separately

@pablogsal pablogsal merged commit 7c79798 into python:3.8 Dec 7, 2020
@brandtbucher brandtbucher deleted the backport-226a012-3.8 branch July 21, 2022 19:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@pablogsal pablogsal pablogsal approved these changes

@methane methane Awaiting requested review from methane methane is a code owner

@rhettinger rhettinger Awaiting requested review from rhettinger rhettinger is a code owner

Assignees
No one assigned
Labels
type-bug An unexpected behavior, bug, or error
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@brandtbucher @pablogsal @the-knights-who-say-ni @bedevere-bot