touch-packages team mailing list archive

[Clark Boylan <clark.boylan@xxxxxxxxx>]

Public bug reported:

Python 3.4 released with a backward incompatible change in the logging module. This bug has been tracked and fixed
upstream in http://bugs.python.org/issue22386. Summary is that logging.getLevelName(lvl)
would return an integer value for a string lvl and a string value for an integer lvl.
It mapped the two representations of log levels to each other. This behavior existed
in python2.6 through python3.3 but was removed in 3.4. The new behavior in 3.4 was to
only map integer lvl values to strings.

[Impact]

Any python code that aims to be compatible with python2.6 and python3.4 must carry its
own log level mappings (which may change under it because the loglevels are extensible)
or access private data within the python logging module. Both approaches are fragile
but thankfully upstream python 3.4 has patched this behavior so a downstream update
to Trusty python3.4 would allow code to easily support 2.6 and 3.4.

[Test Case]

As detailed in the upstream bug you can test this easily via the
interactive interpreter.

Desired Behavior:
>>> logging.getLevelName('INFO')
20
>>> logging.getLevelName(20)
'INFO'
>>> 

Current Trusty Behavior:
# This function call should return 20.
>>> logging.getLevelName('INFO')
'Level INFO'
>>> logging.getLevelName(20)
'INFO'
>>> logging.getLevelName(logging.INFO)
'INFO'
>>> 

[Regression Potential]

The upstream patch is tiny and comes with a test case to track the desired behavior
(upstream already had tests for the other behavior of this function). Beacuse this
patch is so small and comes with new tests I think the regression potential is very
small. Probably the only thing to consider is that new python3.4 code may have come
to rely on this new backward incompatible behavior. But that would only be the case
if code specifically looked for the mapping of 'Level %s' % 'stringlevelhere'.

** Affects: python
     Importance: Unknown
         Status: Unknown

** Affects: python3.4 (Ubuntu)
     Importance: Undecided
         Status: New

** Bug watch added: Python Roundup #22386
   http://bugs.python.org/issue22386

** Also affects: python via
   http://bugs.python.org/issue22386
   Importance: Unknown
       Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python3.4 in Ubuntu.
https://bugs.launchpad.net/bugs/1382607

Title:
  Backport python3.4 logging module backward incompatibility fix.

Status in Python:
  Unknown
Status in “python3.4” package in Ubuntu:
  New

Bug description:
  Python 3.4 released with a backward incompatible change in the logging module. This bug has been tracked and fixed
  upstream in http://bugs.python.org/issue22386. Summary is that logging.getLevelName(lvl)
  would return an integer value for a string lvl and a string value for an integer lvl.
  It mapped the two representations of log levels to each other. This behavior existed
  in python2.6 through python3.3 but was removed in 3.4. The new behavior in 3.4 was to
  only map integer lvl values to strings.

  [Impact]

  Any python code that aims to be compatible with python2.6 and python3.4 must carry its
  own log level mappings (which may change under it because the loglevels are extensible)
  or access private data within the python logging module. Both approaches are fragile
  but thankfully upstream python 3.4 has patched this behavior so a downstream update
  to Trusty python3.4 would allow code to easily support 2.6 and 3.4.

  [Test Case]

  As detailed in the upstream bug you can test this easily via the
  interactive interpreter.

  Desired Behavior:
  >>> logging.getLevelName('INFO')
  20
  >>> logging.getLevelName(20)
  'INFO'
  >>> 

  Current Trusty Behavior:
  # This function call should return 20.
  >>> logging.getLevelName('INFO')
  'Level INFO'
  >>> logging.getLevelName(20)
  'INFO'
  >>> logging.getLevelName(logging.INFO)
  'INFO'
  >>> 

  [Regression Potential]

  The upstream patch is tiny and comes with a test case to track the desired behavior
  (upstream already had tests for the other behavior of this function). Beacuse this
  patch is so small and comes with new tests I think the regression potential is very
  small. Probably the only thing to consider is that new python3.4 code may have come
  to rely on this new backward incompatible behavior. But that would only be the case
  if code specifically looked for the mapping of 'Level %s' % 'stringlevelhere'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/python/+bug/1382607/+subscriptions