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
confusion between frame and frame_summary in traceback module #89238
Comments
def format_frame(frame) should be renamed to format_frame_summary(frame_summary) because it takes a FrameSummary obejct and not a frame. This is a new API in 3.11 so it can be changed now. There are also local variables in traceback.py which are called frame but actually represent FrameSummary. This can be confusing and should be fixed at the same time where it doesn't break API. |
There are places where f is used for an arg or local variable which is a frame, so I'll try f_summary when it's a FrameSummary. |
It might be good to have consistency with what will be used for StackSummary so two different approaches to naming aren't used. By the way, frame_sum is another possibility since I see frame_gen being used. |
I'm not sure I follow. We don't have a similar issue with StackSummary - there is no interpreter type for "stack" that you can confuse it with. |
I was suggesting keeping more similarity between FrameSummary and StackSummary in addition to differentiating frame from FrameSummary. Since stack is used for StackSummary, frame_sum is more similar than f_summary while still providing the differentiation. |
Or frame_info (more readable), since FrameSummary is proposed to be "Information about a single frame from a traceback." |
Yes, frame_info is good. |
Could you make a PR documenting |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: