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
logging module crashes in Python 2.7.3 for handler.setLevel(long) #59915
Comments
I'm using a 3rd-party library (ESAPI) which defines a log level as the literal -2**31. This worked fine until I upgraded to Python 2.7.3, which, unlike all previous versions of Python, coerces that literal to long rather than int. The following code in the logging module then throws a TypeError: def _checkLevel(level):
if isinstance(level, int):
rv = level
elif str(level) == level:
if level not in _levelNames:
raise ValueError("Unknown level: %r" % level)
rv = _levelNames[level]
else:
raise TypeError("Level not an integer or a valid string: %r" % level)
return rv Although this is certainly an unusual use case, it seems that as just a matter of principle, the module should be using the check isinstance(level, (int, long)) rather than just isinstance(level, int). Here's the relevant part of the traceback: File "/usr/lib/python2.7/logging/init.py", line 710, in setLevel |
I don't feel it would be correct to allow long for log levels, since a log level is not intended to have that range. It would be more sensible to get the ESAPI developers to use a more appropriate boundary value; in general, negative log values are not used (they are not necessary). |
This seems to miss the point that it's a regression. int and long are supposed to be interchangeable for most purposes. |
type(-2**31) is long for 2.5 and 2.6 as well as 2.7. The check was added as a response to bpo-6314, to catch incorrect values being passed as levels. It could be argued that -2**31 is not a sensible log level. While int and long are supposed to be interchangeable for most purposes, isn't this a reasonable case where you shouldn't need to support long? If you feel not, what scenarios do you believe lie outside the "most purposes"? |
Well, what is an incorrect value and why would you bother refusing long? |
It's not that big a deal, and doesn't matter for 3.x anyway. It just doesn't seem quite right, so I'll make the change soon. |
New changeset 8ba6d8fc9740 by Vinay Sajip in branch '2.7': |
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:
The text was updated successfully, but these errors were encountered: