Skip to content
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

PEP 654: add number of sub-exceptions to BaseException.__str__ #2356

Merged
merged 1 commit into from
Feb 22, 2022

Conversation

iritkatriel
Copy link
Member

No description provided.

Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

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

I don't see a reason to bother the SC with this level of detail. If they don't like this they can comment on the PR or open a new bpo.

@iritkatriel iritkatriel marked this pull request as ready for review February 22, 2022 16:59
@AA-Turner
Copy link
Member

I don't see a reason to bother the SC with this level of detail. If they don't like this they can comment on the PR or open a new bpo.

This change looks fine from an editor perspective; would you like to keep it open for some time to allow the Council to comment or are you happy for it to be merged?

A

@iritkatriel iritkatriel merged commit 4e06e44 into python:main Feb 22, 2022
@iritkatriel
Copy link
Member Author

Let's merge, we can always change it if there's an issue.

@CAM-Gerlach CAM-Gerlach changed the title PEP-654: add number of sub-exceptions to BaseException.__str__ PEP 654: add number of sub-exceptions to BaseException.__str__ Feb 22, 2022
@CAM-Gerlach
Copy link
Member

CAM-Gerlach commented Feb 22, 2022

Just FYI, @python/pep-editors , its probably a good idea to check for and fix PR titles to ensure they follow the standard PEP N: <desc> format, since that is what gets set as the commit message for the squashed commit, and its very quick and painless to do without bothering the PR author. PR #2352 includes better language for this in the Contributing Guide, making it clearer and more explicit that PR titles (as well as the commit summary lines already discussed) should follow the format, since the former get turned in to the latter (of course, it can be fixed on merge, but better and more reliable to do it before).

@AA-Turner
Copy link
Member

I normally do this when merging commits rather than changing the title, but I generally agree (to the extent of labelling most of my infrastructure PRs under PEP 676!)

A

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants