Skip to content

[3.12] gh-114480: Add docs for f_trace_opcodes behavior on 3.12 #114540

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

Merged
merged 3 commits into from
Feb 4, 2024

Conversation

gaogaotiantian
Copy link
Member

@gaogaotiantian gaogaotiantian commented Jan 24, 2024

3.12 introduced a weird behavior for f_trace_opcodes due to PEP 669. We should document it. However, this behavior is fixed in main (3.13) so we only need to document it in 3.12 branch.


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

@gaogaotiantian
Copy link
Member Author

Hi @AlexWaygood , do you think a version change section works for this behavior description? Thanks!

Copy link
Member

@AlexWaygood AlexWaygood left a comment

Choose a reason for hiding this comment

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

Thanks! This looks good, but I think it's worth pointing out:

  1. in the 3.12 docs that the behaviour has already changed in 3.13
  2. in the 3.13 docs that the behaviour changed between Python 3.12 and Python 3.13

We had a similar situation with typing.NewType. In the 3.10 branch, there's a .. versionchanged note in the typing module docs that says:

Changed in version 3.10: NewType is now a class rather than a function. There is some additional runtime cost when calling NewType over a regular function. However, this cost will be reduced in 3.11.0.

In the 3.11 branch, there are two .. versionchanged notes that say:

Changed in version 3.10: NewType is now a class rather than a function. As a result, there is some additional runtime cost when calling NewType over a regular function.

Changed in version 3.11: The performance of calling NewType has been restored to its level in Python 3.9.

Could we do something similar here?

@gaogaotiantian
Copy link
Member Author

We can surely mention that the behavior has changed in 3.13 in 3.12 docs. I was wondering if we should mention this in 3.13. This behavior was consistent until 3.12, and simply went back to what it used to be in 3.13. Will the extra doc confuse users if they never realize the change in 3.12? It's not difficult to add the docs to 3.13, just thinking about what's the best for the users.

@AlexWaygood
Copy link
Member

Good point; maybe it's sufficient just to mention this in the 3.12 docs, as long as we say that it will change back in python 3.13

@gaogaotiantian
Copy link
Member Author

Do you think it's better now? I used "is" instead of "will be" because we have 3.13 alpha release now and it should already be different. Not sure what's the best to phrase it.

Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Copy link
Member

@AlexWaygood AlexWaygood left a comment

Choose a reason for hiding this comment

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

Thanks!

@AlexWaygood AlexWaygood merged commit 27cacdd into python:3.12 Feb 4, 2024
@gaogaotiantian gaogaotiantian deleted the 3.12-sys-settrace-docs branch March 14, 2024 21:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation in the Doc dir skip news
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants