-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
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
bpo-15999: Accept arbitrary values for boolean parameters. #15609
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks good. Though I do wonder if PyObject_IsTrue
is the best behavior for users? The behavior of all objects being True by default is understandable but could lead to some confusion if someone passes the wrong parameter in the wrong place and no longer gets an exception.
We don't have, and probably do not want, a PyObject_IsExplicitlyTrueOrRaise
API (if it existed I'd just want it to change the default case of True to raise a TypeError). So lets go with this as it is consistent with how most pure Python code is written.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has merge conflicts now.
When you're done making the requested changes, leave the comment: |
|
Oh. The truth is that this PR was not intended to be merged. This is just a demonstration to see how much needs to be changed to achieve this and which tests will be broken in result. I also worked on the opposite change -- to make only True and False (and maybe 1 and 0 for compatibility) be accepted as boolean argument. |
Want me to revert it? I was wondering about the utility, but the comment I apparently left here in 2019 still made sense to me: Accepting anything for bool is still more consistent with how pure Python code behaves. |
No need to rush, it will only increase the code churn. I will first try to finish the opposite patch. Yes, accepting arbitrary Python object is more consistent with the pure Python code, but on other hand, it is more error prone, especially for positional arguments. Even for keyword arguments, there are cases in which silently accepting arbitrary Python object as boolean can hide an error. For example if you pass |
Process note: the DO-NOT-MERGE label should probably not be removed before checking with the person who added it. |
Next time I would use the draft mode. This PR was created before introducing of that feature. |
https://bugs.python.org/issue15999
#60203