Skip to content

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

Merged
AlexWaygood merged 3 commits intopython:3.12from
gaogaotiantian:3.12-sys-settrace-docs
Feb 4, 2024
Merged

[3.12] gh-114480: Add docs for f_trace_opcodes behavior on 3.12#114540
AlexWaygood merged 3 commits intopython:3.12from
gaogaotiantian:3.12-sys-settrace-docs

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