10000 gh-106168: Revert the "size before item" setting by scoder · Pull Request #111683 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

gh-106168: Revert the "size before item" setting #111683

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
Nov 3, 2023
Merged

gh-106168: Revert the "size before item" setting #111683

merged 1 commit into from
Nov 3, 2023

Conversation

scoder
Copy link
Contributor
@scoder scoder commented Nov 3, 2023 •
edited by github-actions bot
Loading

Update the size only after setting the item, to avoid temporary inconsistencies.

Also remove the "what's new" sentence regarding the size setting since tuples cannot grow after allocation.

📚 Documentation preview 📚: https://cpython-previews--111683.org.readthedocs.build/

@scoder
pythongh-106168: Update the size only after setting the item, to avoi…
6b19abb 
…d temporary inconsistencies.

Also remove the "what's new" sentence regarding the size setting since tuples cannot grow after allocation.
@bedevere-app bedevere-app bot mentioned this pull request Nov 3, 2023
Closed
@scoder scoder requested a review from vstinner November 3, 2023 08:42
vstinner
vstinner approved these changes Nov 3, 2023
View reviewed changes
Copy link
Member
@vstinner vstinner left a comment

Choose a reason for hiding this comment

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

LGTM.

With the GIL, _PyList_AppendTakeRef() and list_extend() change are not important: setting the item first or setting the size first, both are safe. But when I read the code and attempt to imagine a "free threading" (NoGIL) world, yeah, I see that the Python 3.12 code looks more correct: first set the item, then announce that the list is one item longer.

Moreover I only made these 2 changes when PyList_SET_ITEM() rejected writes outside 0..size range, which is no longer the case. So I'm fine with reverting these changes.

Doc/whatsnew/3.13.rst
@@ -1048,8 +1048,6 @@ New Features
* If Python is built in :ref:`debug mode <debug-build>` or :option:`with
assertions <--with-assertions>`, :c:func:`PyTuple_SET_ITEM` and
:c:func:`PyList_SET_ITEM` now check the index argument with an assertion.
If the assertion fails in :c:func:`PyTuple_SET_ITEM`, make sure that the
tuple size is set before.
Copy link
Member

Choose a reason for hiding this comment

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

I was sure that I had issues with PyTuple_SET_ITEM() and code setting the tuple size just after that. But I checked again https://github.com/python/cpython/pull/106164/files and I was wrong: the problem was specific to lists, and your change (allow write into 0..allocated range) makes this sentence outdated. I'm fine with removing it.

@vstinner vstinner enabled auto-merge (squash) November 3, 2023 11:02
@vstinner vstinner merged commit 24ddaee into python:main Nov 3, 2023
@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot s390x SLES 3.x has failed when building commit 24ddaee.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/540/builds/7057) and take a look at the build logs.
  4. Check if the failure is related to this commit (24ddaee) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/540/builds/7057

Summary of the results of the build (if available):

==

Click to see traceback logs 
remote: Enumerating objects: 19, done.        
remote: Counting objects:   5% (1/19)        
remote: Counting objects:  10% (2/19)        
remote: Counting objects:  15% (3/19)        
remote: Counting objects:  21% (4/19)        
remote: Counting objects:  26% (5/19)        
remote: Counting objects:  31% (6/19)        
remote: Counting objects:  36% (7/19)        
remote: Counting objects:  42% (8/19)        
remote: Counting objects:  47% (9/19)        
remote: Counting objects:  52% (10/19)        
remote: Counting objects:  57% (11/19)        
remote: Counting objects:  63% (12/19)        
remote: Counting objects:  68% (13/19)        
remote: Counting objects:  73% (14/19)        
remote: Counting objects:  78% (15/19)        
remote: Counting objects:  84% (16/19)        
remote: Counting objects:  89% (17/19)        
remote: Counting objects:  94% (18/19)        
remote: Counting objects: 100% (19/19)        
remote: Counting objects: 100% (19/19), done.        
remote: Compressing objects:  12% (1/8)        
remote: Compressing objects:  25% (2/8)        
remote: Compressing objects:  37% (3/8)        
remote: Compressing objects:  50% (4/8)        
remote: Compressing objects:  62% (5/8)        
remote: Compressing objects:  75% (6/8)        
remote: Compressing objects:  87% (7/8)        
remote: Compressing objects: 100% (8/8)        
remote: Compressing objects: 100% (8/8), done.        
remote: Total 10 (delta 9), reused 2 (delta 2), pack-reused 0        
From https://github.com/python/cpython
 * branch                  main       -> FETCH_HEAD
Note: switching to '24ddaee5ca112063b460e72d31b3da551a02bf0a'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 24ddaee5ca gh-106168: Revert the "size before item" setting (#111683)
Switched to and reset branch 'main'

make: *** [Makefile:2062: buildbottest] Error 3

@bedevere-bot
8000 Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot AMD64 FreeBSD 3.x has failed when building commit 24ddaee.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/1223/builds/661) and take a look at the build logs.
  4. Check if the failure is related to this commit (24ddaee) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/1223/builds/661

Summary of the results of the build (if available):

==

Click to see traceback logs 
remote: Enumerating objects: 19, done.        
remote: Counting objects:   5% (1/19)        
remote: Counting objects:  10% (2/19)        
remote: Counting objects:  15% (3/19)        
remote: Counting objects:  21% (4/19)        
remote: Counting objects:  26% (5/19)        
remote: Counting objects:  31% (6/19)        
remote: Counting objects:  36% (7/19)        
remote: Counting objects:  42% (8/19)        
remote: Counting objects:  47% (9/19)        
remote: Counting objects:  52% (10/19)        
remote: Counting objects:  57% (11/19)        
remote: Counting objects:  63% (12/19)        
remote: Counting objects:  68% (13/19)        
remote: Counting objects:  73% (14/19)        
remote: Counting objects:  78% (15/19)        
remote: Counting objects:  84% (16/19)        
remote: Counting objects:  89% (17/19)        
remote: Counting objects:  94% (18/19)        
remote: Counting objects: 100% (19/19)        
remote: Counting objects: 100% (19/19), done.        
remote: Compressing objects:  12% (1/8)        
remote: Compressing objects:  25% (2/8)        
remote: Compressing objects:  37% (3/8)        
remote: Compressing objects:  50% (4/8)        
remote: Compressing objects:  62% (5/8)        
remote: Compressing objects:  75% (6/8)        
remote: Compressing objects:  87% (7/8)        
remote: Compressing objects: 100% (8/8)        
remote: Compressing objects: 100% (8/8), done.        
remote: Total 10 (delta 9), reused 2 (delta 2), pack-reused 0        
From https://github.com/python/cpython
 * branch                  main       -> FETCH_HEAD
Note: switching to '24ddaee5ca112063b460e72d31b3da551a02bf0a'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 24ddaee5ca gh-106168: Revert the "size before item" setting (#111683)
Switched to and reset branch 'main'

aisk pushed a commit to aisk/cpython that referenced this pull request Feb 11, 2024
@scoder @aisk
pythongh-106168: Revert the "size before item" setting (python#111683)
1193f1d 
pythongh-106168: Update the size only after setting the item, to avoid temporary inconsistencies.
Also remove the "what's new" sentence regarding the size setting since tuples cannot grow after allocation.
Glyphack pushed a commit to Glyphack/cpython that referenced this pull request Sep 2, 2024
@scoder @Glyphack
pythongh-106168: Revert the "size before item" setting (python#111683)
edfc396 
pythongh-106168: Update the size only after setting the item, to avoid temporary inconsistencies.
Also remove the "what's new" sentence regarding the size setting since tuples cannot grow after allocation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@vstinner vstinner vstinner approved these changes

Assignees
No one assigned
Labels
skip news
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@scoder @bedevere-bot @vstinner
0