-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
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
Using new 'bool' format character #60203
Comments
bpo-14705 added 'bool' format character to PyArg_ParseTuple for using it for parsing multiple boolean arguments in os module. The proposed patch uses this format character for other boolean arguments. This makes the sources simpler, clearer and more reliable, improves error messages, gets rid of a few rare errors. |
Patch looks fine in principle, though I'd want someone to go over the individual cases to make sure they make sense. Also, I have something up my sleeve regarding argument parsing for 3.4, and if it gets accepted we might be touching all this code anyway. I mention this just to say--you may want to hold off on more patches like this for now. |
Has this been entirely superseded by Argument Clinic? |
No, it is orthogonal to Argument Clinic. Usually converting to Argument Clinic didn't change semantic. However these changes conflicted with proposed patch. Rebased patch is splitted on two patches. bool_cleanup.patch. It almost doesn't change the behavior. It uses the "p" format unit instead of manually called PyObject_IsTrue(), passes boolean value instead 0/1 integers to functions that needs boolean, and made some arguments ("flush" in print(), "strict", "sort_keys" and "skipkeys" in json module) to be converted to boolean only once. accept_bool.patch. It makes a number of functions to accept arbitrary objects in boolean context, not just False/True and ints representable as C int. But I prefer first to commit the patch for bpo-24037. |
#15609 was merged. I didn't try to figure out if there were any more of these left, that PR from @serhiy-storchaka took care of a large number of them. |
I'll close this issue as the end point isn't well defined with something we can easily check "[x] Complete" on. But it could be considered ongoing work to clean up any remaining. Feel free to re-open if anyone has identified more. Or just file new more specific issues for each area of the codebase still being overly pedantic about bool in C code. |
reopening to track the conversation on the merged PR around if we actually want it or not. |
In case if only True/False be supported as boolean arguments in future, we should continue to support 1/0 here.
Unless we explicitly test non-bool values.
…ythonGH-99983) Unless we explicitly test non-bool values. (cherry picked from commit 76f43fc) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
… tests (pythonGH-99983) Unless we explicitly test non-bool values.. (cherry picked from commit 76f43fc) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
) Unless we explicitly test non-bool values. (cherry picked from commit 76f43fc) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Opened a discussion: https://discuss.python.org/t/boolean-arguments/21662 Gregory, please join. Feel free to rewrite my post or add your explanations (you are better in this). |
In case if only True/False be supported as boolean arguments in future, we should continue to support 1/0 here.
Seems the decision was to simply accept this. So I close this issue. |
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:
Linked PRs
The text was updated successfully, but these errors were encountered: