Fix typo in gc.c

[dzhalaevd]

No description provided.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[dzhalaevd]

@Eclips4 could you review pls ^_^

[brianschubert]

Sorry, we don't accept typo fixes for internal comments as it is code churn. Typos can be fixed for user-facing text (e.g. docs or docstrings). Please see the dev guide for more information about what kinds of contributions are accepted: https://devguide.python.org/

[Eclips4]

@brianschubert Hi! Do we really have something about this in the devguide? I don't remember anything about that and can't find it. Can you please show me the part of the devguide you're referring to? I was always under the impression that this kind of PR is acceptable, but maybe I'm wrong.

[brianschubert]

@Eclips4 we've closed similar PRs in the past, see e.g. #143979 (comment), #144241 (comment). I'm not sure this is spelled out in the dev guide, it's more of the de facto policy from some internal discussions on discord. Possibly @picnixz can point to where the quote in the second comment came from.

[dzhalaevd]

@Eclips4 we've closed similar PRs in the past, see e.g. #143979 (comment), #144241 (comment). I'm not sure this is spelled out in the dev guide, it's more of the de facto policy from some internal discussions on discord. Possibly @picnixz can point to where the quote in the second comment came from.

Hi, there are also similar pr which were merged #118024, #97766, #142612 e.g I’m not sure what the difference is.

[picnixz]

The difference is between a user facing change (docs, rst, help(), online docs, etc) vs comments that you only see in the source code.

[picnixz]

can point to where the quote in the second comment came from.

The second quote comes from me and my past interactions with triaging. The general rule is to avoid code churn as much as possible as this creates branches divergences. AS for the quote it's in https://devguide.python.org/getting-started/pull-request-lifecycle/#making-good-prs:

Pull requests with only code formatting changes are usually rejected. On the other hand, fixes for typos and grammar errors in documents and docstrings are welcome.

[picnixz]

As for #118024 and #142612, we shouldn't have merged them but if a core dev decides to do it, it's another story (it's left at the discretion of core devs whether to merge changes or not and usually at the codeowner's discretion).

For #97766, it's because it's the docstring that was modified hence user-facing.