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
    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

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 #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"?

> type(-2**31) is long for 2.5 and 2.6 as well as 2.7. The check was
> added as a response to #6314, to catch incorrect values being passed
> as levels.

Well, what is an incorrect value and why would you bother refusing long?
And how about small long values (e.g. long(0))?

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':
Closes #15710: accept long in _checkLevel.
http://hg.python.org/cpython/rev/8ba6d8fc9740