gh-111230: Fix _ssl.c not checking for errors when initializing a module

[sobolevn]

.. c:function::intPyModule_AddIntConstant(PyObject *module, const char *name, long value) Add an integer constant to *module* as *name*. This convenience function can be used from the module's initialization function. Return ``-1`` on error, ``0`` on success.

I've used _PyModule_ADD_INT_CONST macro name to make the diff minimal:

• It has the same length as PyModule_AddIntConstant
• So, you don't have to reformat the second line of code

• Issue: _ssl.c does not handle errors on module creation #111230

[serhiy-storchaka]

LGTM, but I would prefer to not use ALL_CAPS for macro parameters (here, and in your other PRs). It is very unusual (and perhaps against PEP 7). Please only use ALL_CAPS for macro names.

[sobolevn]

@serhiy-storchaka I think that this is the style suggested and prefered by @erlend-aasland, I am ok with both.

[erlend-aasland]

It is very unusual (and perhaps against PEP 7).

There is no mention of macro arguments in PEP-7; please do not spread uncertainty and doubt like this.

I personally prefer ALL_CAPS macro parameters since it makes them stand out better from implicit variables that are not part of the macro "scope"; for example, many macros are used in extension module initialisation phase, and very often, the module object is implicitly used from within the macro. Using ALL_CAPS macro parameters makes it clear that these parameters are text strings (and not variables) that will be replaced by the pre-processor.

Also, note that this style is used other places in the code base by other core devs.

[miss-islington-app]

Thanks @sobolevn for the PR, and @erlend-aasland for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11.
🐍🍒⛏🤖

[miss-islington-app]

Thanks @sobolevn for the PR, and @erlend-aasland for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12.
🐍🍒⛏🤖

[miss-islington-app]

Sorry, @sobolevn and @erlend-aasland, I could not cleanly backport this to 3.11 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker f6304949bb9937e798ecac8b414606dc01bc6d3c 3.11

[miss-islington-app]

Sorry, @sobolevn and @erlend-aasland, I could not cleanly backport this to 3.12 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker f6304949bb9937e798ecac8b414606dc01bc6d3c 3.12

[bedevere-bot]

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot AMD64 FreeBSD14 3.x has failed when building commit f630494.

What do you need to do:

1. Don't panic.
2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/1232/builds/358) and take a look at the build logs.
4. Check if the failure is related to this commit (f630494) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/1232/builds/358

Failed tests:

• test_interpreters

Summary of the results of the build (if available):

==

Click to see traceback logs

remote: Enumerating objects: 16, done. remote: Counting objects: 6% (1/16) remote: Counting objects: 12% (2/16) remote: Counting objects: 18% (3/16) remote: Counting objects: 25% (4/16) remote: Counting objects: 31% (5/16) remote: Counting objects: 37% (6/16) remote: Counting objects: 43% (7/16) remote: Counting objects: 50% (8/16) remote: Counting objects: 56% (9/16) remote: Counting objects: 62% (10/16) remote: Counting objects: 68% (11/16) remote: Counting objects: 75% (12/16) remote: Counting objects: 81% (13/16) remote: Counting objects: 87% (14/16) remote: Counting objects: 93% (15/16) remote: Counting objects: 100% (16/16) remote: Counting objects: 100% (16/16), done. remote: Compressing objects: 11% (1/9) remote: Compressing objects: 22% (2/9) remote: Compressing objects: 33% (3/9) remote: Compressing objects: 44% (4/9) remote: Compressing objects: 55% (5/9) remote: Compressing objects: 66% (6/9) remote: Compressing objects: 77% (7/9) remote: Compressing objects: 88% (8/9) remote: Compressing objects: 100% (9/9) remote: Compressing objects: 100% (9/9), done. remote: Total 9 (delta 7), reused 1 (delta 0), pack-reused 0 
From https://github.com/python/cpython
* branch main -> FETCH_HEAD
Note: switching to 'f6304949bb9937e798ecac8b414606dc01bc6d3c'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at f6304949bb gh-111230: Fix errors checking in _ssl module init (#111232)
Switched to and reset branch 'main'
configure: WARNING: pkg-config is missing. Some dependencies may not be detected correctly.

[serhiy-storchaka]

Indeed, PEP 7 does not specify it explicitly. But all examples in PEP 7 and AFAIK all existing macros write parameter names in lower case. If some macros write it in upper case, it perhaps a new tendency, I never seen this before. I think that it should be specified in PEP 7 explicitly.

[serhiy-storchaka]

I created a new discussion for this: https://discuss.python.org/t/all-caps-for-macro-parameter-names/37119.

[erlend-aasland]

I think that it should be specified in PEP 7 explicitly.

I agree.

I created a new discussion for this: https://discuss.python.org/t/all-caps-for-macro-parameter-names/37119.

Thanks!

[hugovk]

Sorry, @sobolevn and @erlend-aasland, I could not cleanly backport this to 3.11 due to a conflict. Please backport using cherry_picker on command line.

cherry_picker f6304949bb9937e798ecac8b414606dc01bc6d3c 3.11

@sobolevn@erlend-aasland Does this still need backporting? If not, let's close #111230.

[vstinner]

Taking care of all error paths in an module init function is nice, but I don't think that it's very important to backport. I'm fine with closing the issue, unless @sobolevn is very excited to backport his change :-) @sobolevn: it's up to you ;-)