[SRU] Backport python3.4 logging module backward incompatibility fix.

Bug #1382607 reported by Clark Boylan on 2014-10-17
This bug report is a duplicate of:  Bug #1348954: update Python3 for trusty. Edit Remove
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
python3.4 (Ubuntu)

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.


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')
>>> logging.getLevelName(20)

Current Trusty Behavior:
# This function call should return 20.
>>> logging.getLevelName('INFO')
'Level INFO'
>>> logging.getLevelName(20)
>>> logging.getLevelName(logging.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'.

Related branches

Clark Boylan (cboylan) wrote :

I should also note that https://hg.python.org/cpython/rev/a4c5effb8698 is where the upstream bug was fixed.

summary: - Backport python3.4 logging module backward incompatibility fix.
+ [SRU] Backport python3.4 logging module backward incompatibility fix.
Clint Byrum (clint-fewbar) wrote :

API breaks are bad, mmmkay. Setting to Critical.

Changed in python3.4 (Ubuntu):
status: New → Triaged
importance: Undecided → Critical
Changed in python3.4 (Ubuntu Trusty):
status: New → Triaged
importance: Undecided → High
Changed in python3.4 (Ubuntu Utopic):
importance: Critical → High
Clint Byrum (clint-fewbar) wrote :

Forgetting myself, dropping to "High" .. we need this to be fixed really soon, but it doesn't break EVERYBODY

Clint Byrum (clint-fewbar) wrote :

This is fixed upstream in 3.4.2, so it only affects Trusty.

Changed in python3.4 (Ubuntu Utopic):
status: Triaged → Fix Released
Changed in python3.4 (Ubuntu Trusty):
assignee: nobody → Clint Byrum (clint-fewbar)
status: Triaged → In Progress
Changed in python:
status: Unknown → Fix Released
Clint Byrum (clint-fewbar) wrote :

Looks like there is a backport of 3.4.2 to trusty in the works tracking at bug #1348954

Changed in python3.4 (Ubuntu Trusty):
assignee: Clint Byrum (clint-fewbar) → nobody
status: In Progress → Triaged
Jeremy Stanley (fungi) wrote :

Is the plan to solve this in Trusty via bug 1348954 or to separately SRU the upstream patch?

Jeremy Stanley (fungi) wrote :

Based on E-mail discussion with Barry and Matthias, it sounds like the plan now is to SRU MRE Python 3.4.3 into Trusty once it's available (due out February 22, 2015 according to the official release schedule).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.