-
-
Couldn't load subscription status.
- Fork 33.3k
bpo-42644: Validate values in logging.disable() #23786
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
Conversation
Technically make the value of manager a property that checks and convert values assigned to it properly. This has the side effect of making `logging.disable` also accept strings representing the various level of warnings. We want to validate the type of the disable attribute at assignment time, as it is later compared to other levels when emitting warnings and would generate a `TypeError: '>=' not supported between ....` in a different part of the code base, which can make it difficult to track down. When assigned an incorrect value; it will raise a TypeError when the wrong type, or ValueError if an invalid str.
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.
LGTM except the NEWS cleanup
Misc/NEWS.d/next/Library/2020-12-15-10-00-04.bpo-42644.XgLCNx.rst
Outdated
Show resolved
Hide resolved
|
@asvetlov: Please replace |
* bpo-42644: Validate values in logging.disable() Technically make the value of manager a property that checks and convert values assigned to it properly. This has the side effect of making `logging.disable` also accept strings representing the various level of warnings. We want to validate the type of the disable attribute at assignment time, as it is later compared to other levels when emitting warnings and would generate a `TypeError: '>=' not supported between ....` in a different part of the code base, which can make it difficult to track down. When assigned an incorrect value; it will raise a TypeError when the wrong type, or ValueError if an invalid str. Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com> (cherry picked from commit b32d8b4) Co-authored-by: Matthias Bussonnier <bussonniermatthias@gmail.com>
|
GH-23796 is a backport of this pull request to the 3.9 branch. |
* bpo-42644: Validate values in logging.disable() Technically make the value of manager a property that checks and convert values assigned to it properly. This has the side effect of making `logging.disable` also accept strings representing the various level of warnings. We want to validate the type of the disable attribute at assignment time, as it is later compared to other levels when emitting warnings and would generate a `TypeError: '>=' not supported between ....` in a different part of the code base, which can make it difficult to track down. When assigned an incorrect value; it will raise a TypeError when the wrong type, or ValueError if an invalid str. Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com> (cherry picked from commit b32d8b4) Co-authored-by: Matthias Bussonnier <bussonniermatthias@gmail.com>
|
GH-23797 is a backport of this pull request to the 3.8 branch. |
* bpo-42644: Validate values in logging.disable() Technically make the value of manager a property that checks and convert values assigned to it properly. This has the side effect of making `logging.disable` also accept strings representing the various level of warnings. We want to validate the type of the disable attribute at assignment time, as it is later compared to other levels when emitting warnings and would generate a `TypeError: '>=' not supported between ....` in a different part of the code base, which can make it difficult to track down. When assigned an incorrect value; it will raise a TypeError when the wrong type, or ValueError if an invalid str. Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com> (cherry picked from commit b32d8b4) Co-authored-by: Matthias Bussonnier <bussonniermatthias@gmail.com>
* bpo-42644: Validate values in logging.disable() Technically make the value of manager a property that checks and convert values assigned to it properly. This has the side effect of making `logging.disable` also accept strings representing the various level of warnings. We want to validate the type of the disable attribute at assignment time, as it is later compared to other levels when emitting warnings and would generate a `TypeError: '>=' not supported between ....` in a different part of the code base, which can make it difficult to track down. When assigned an incorrect value; it will raise a TypeError when the wrong type, or ValueError if an invalid str. Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com> (cherry picked from commit b32d8b4) Co-authored-by: Matthias Bussonnier <bussonniermatthias@gmail.com>
|
Thanks @Carreau |
* bpo-42644: Validate values in logging.disable() Technically make the value of manager a property that checks and convert values assigned to it properly. This has the side effect of making `logging.disable` also accept strings representing the various level of warnings. We want to validate the type of the disable attribute at assignment time, as it is later compared to other levels when emitting warnings and would generate a `TypeError: '>=' not supported between ....` in a different part of the code base, which can make it difficult to track down. When assigned an incorrect value; it will raise a TypeError when the wrong type, or ValueError if an invalid str. Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
Technically make the value of manager a property that checks and convert
values assigned to it properly. This has the side effect of making
logging.disablealso accept strings representing the various level ofwarnings.
We want to validate the type of the disable attribute at assignment
time, as it is later compared to other levels when emitting warnings and
would generate a
TypeError: '>=' not supported between ....in adifferent part of the code base, which can make it difficult to track
down.
When assigned an incorrect value; it will raise a TypeError when the
wrong type, or ValueError if an invalid str.
https://bugs.python.org/issue42644