Repository navigation
logging module crashes in Python 2.7.3 for handler.setLevel(long) #59915
Description
| BPO | 15710 |
|---|---|
| Nosy | @vsajip, @pitrou, @merwok |
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:
assignee = None
closed_at = <Date 2012-08-29.13:34:07.486>
created_at = <Date 2012-08-16.21:33:58.925>
labels = ['type-feature', 'library']
title = 'logging module crashes in Python 2.7.3 for handler.setLevel(long)'
updated_at = <Date 2012-08-29.13:34:07.484>
user = 'https://bugs.python.org/tobinbaker'bugs.python.org fields:
activity = <Date 2012-08-29.13:34:07.484>
actor = 'python-dev'
assignee = 'none'
closed = True
closed_date = <Date 2012-08-29.13:34:07.486>
closer = 'python-dev'
components = ['Library (Lib)']
creation = <Date 2012-08-16.21:33:58.925>
creator = 'tobin.baker'
dependencies = []
files = []
hgrepos = []
issue_num = 15710
keywords = []
message_count = 7.0
messages = ['168418', '169018', '169019', '169069', '169073', '169077', '169378']
nosy_count = 5.0
nosy_names = ['vinay.sajip', 'pitrou', 'eric.araujo', 'python-dev', 'tobin.baker']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue15710'
versions = ['Python 2.7']
Activity
tobinbaker commentedon Aug 16, 2012
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:
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
self.level = _checkLevel(level)
File "/usr/lib/python2.7/logging/init.py", line 190, in _checkLevel
raise TypeError("Level not an integer or a valid string: %r" % level)
TypeError: Level not an integer or a valid string: -2147483648L
vsajip commentedon Aug 24, 2012
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).
pitrou commentedon Aug 24, 2012
This seems to miss the point that it's a regression. int and long are supposed to be interchangeable for most purposes.
vsajip commentedon Aug 24, 2012
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"?
pitrou commentedon Aug 24, 2012
Well, what is an incorrect value and why would you bother refusing long?
And how about small long values (e.g. long(0))?
vsajip commentedon Aug 24, 2012
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.
python-dev commentedon Aug 29, 2012
New changeset 8ba6d8fc9740 by Vinay Sajip in branch '2.7':
Closes bpo-15710: accept long in _checkLevel.
http://hg.python.org/cpython/rev/8ba6d8fc9740