Fix typo 'Calculate'

[xatier]

No description provided.

[the-knights-who-say-ni]

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

Recognized GitHub username

We couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames:

@xatier

This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

[xatier]

Also found out other typos

L262: possible
L268-271: existing_state

[xatier]

To reviewers: I do not want to create an account on bugs.python.org, neither do I want to provide my personal information in the CLA form. Feel free to drop the PR if CLA is required for merge.

[aeros]

@xatier Thanks for the PR and welcome!

To reviewers: I do not want to create an account on bugs.python.org, neither do I want to provide my personal information in the CLA form. Feel free to drop the PR if CLA is required for merge.

IIRC, we are typically okay with merging minor typo fixes without the CLA (at least based on prior precedent). That being said, it may reduce the pool of core developers willing to merge to PR in case there are any issues. This may result in an increased delay for merging the PR.

That being said, LGTM. I'll add labels to skip the news entry and bpo issue, as it's not needed for typo fixes. (:

Note: backporting is not applicable for this PR since it doesn't exist on the 3.8 and 3.7 branches.

[xatier]

@aeros, sounds good! Thanks for your reply! This can definitely wait, there's no harm for the delay.

Would you like me to include the other two typos I mentioned above to this PR, or you would prefer a separate PR for those?

Thanks for your time! 🙏

[aeros]

Would you like me to include the other two typos I mentioned above to this PR, or you would prefer a separate PR for those?

It will likely be easier to further review and have merged with just the existing changes (since I already approved of it), but in the future for fixing typos it's okay to combine multiple across different areas, particularly if they're entirely uncontroversial (clear grammatical/spelling errors).

Thanks for your time!

No problem. (:

[pablogsal]

@aeros @xatier Sadly, for legal reasons, we cannot merge any PR from a contributor that has not signed the CLA. If you want I could make a PR myself with your patch and mention your name in the commit, but otherwise, you (and any contributor) need to sign the CLA to contribute to CPython.

[aeros]

@pablogsal

Sadly, for legal reasons, we cannot merge any PR from a contributor that has not signed the CLA. If you want I could make a PR myself with your patch and mention your name in the commit, but otherwise, you (and any contributor) need to sign the CLA to contribute to CPython.

If that is indeed the case, then I think we need to be more consistent about this policy. There are currently a fairly large number of recently merged PRs with rather minimal documentation changes (similar to this one) that were merged without the CLA being signed: https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Apr+state%3Amerged+label%3A%22CLA+not+signed%22

IMO, this is worth opening a thread on python-dev about it. I personally don't have any strong objections to specifically requiring the CLA to be signed for all PRs, especially if there are genuine legal concerns, but I think we should at least be consistent about it so it's fair to all contributors.

I should have time to start a new thread on this discussion in the next couple of days or so.

Edit: changed link to not filter out miss-islington, as the label is based on whether the original author signed the CLA. This would needlessly exclude PRs merged via the automerge label.

[pablogsal]

, then I think we need to be more consistent about this policy.

I think so as well, especially because there is no list of situations approved by the PSF where the CLA is not needed. The reason is that we legally need the CLA to be signed to distribute Python with the current licence.

I should have time to start a new thread on this discussion in the next couple of days or so.

If you could find some spare cycles to start the thread that would be great! Thanks!

[xatier]

@aeros, got it. I'll keep this PR as one single change. I (or other folks) can have other PRs to fix the rest two typos I found.

@pablogsal @aeros, Agree with that it is worth to have a separate python-dev discussion to establish some policies, etc. I am not in hurry at all and willing to see such policy been discussed and implemented. :D

[aeros]

@xatier Based on the discussion in the python-dev thread, the consensus seems to be that it's up to individual core developers to decide if they want to merge "trivial" PRs without the CLA signed; some are comfortable with it and others aren't.

As to what defines a PR as being adequately "trivial", Brett Cannon summed it up nicely:

https://mail.python.org/archives/list/[email protected]/message/QQYQSI3X26IK23MJPEQJKYNLTVZSVHP3/

Terry Reedy went a bit more in-depth with copyrightable vs non-copyrightable:

https://mail.python.org/archives/list/[email protected]/message/UARCSQSBLTU2YHOM4QDTGNYXXDWVM26W/

Based on the above, I think that it would be reasonable to merge this PR without the CLA signed since it's a simple typo fix, but you may have to wait until a core dev willing to do so finds the time to merge it.

[pablogsal]

I will go ahead and merge this based on the discussion, but if you plan to keep contributing, please, consider signing the CLA :)

[xatier]

Thank you so much!