[Touch-packages] [Bug 1382607] Re: [SRU] Backport python3.4 logging module backward incompatibility fix.
*** This bug is a duplicate of bug 1348954 ***
https://bugs.launchpad.net/bugs/1348954
** This bug has been marked a duplicate of bug 1348954
update Python3 for trusty
--
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:
[SRU] Backport python3.4 logging module backward incompatibility fix.
Status in Python:
Fix Released
Status in python3.4 package in Ubuntu:
Fix Released
Status in python3.4 source package in Trusty:
Triaged
Status in python3.4 source package in Utopic:
Fix Released
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1382607] Re: [SRU] Backport python3.4 logging module backward incompatibility fix.
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).
--
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:
[SRU] Backport python3.4 logging module backward incompatibility fix.
Status in Python:
Fix Released
Status in python3.4 package in Ubuntu:
Fix Released
Status in python3.4 source package in Trusty:
Triaged
Status in python3.4 source package in Utopic:
Fix Released
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1382607] Re: [SRU] Backport python3.4 logging module backward incompatibility fix.
Is the plan to solve this in Trusty via bug 1348954 or to separately SRU
the upstream patch?
--
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:
[SRU] Backport python3.4 logging module backward incompatibility fix.
Status in Python:
Fix Released
Status in “python3.4” package in Ubuntu:
Fix Released
Status in “python3.4” source package in Trusty:
Triaged
Status in “python3.4” source package in Utopic:
Fix Released
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1382607] Re: [SRU] Backport python3.4 logging module backward incompatibility fix.
** Summary changed:
- Backport python3.4 logging module backward incompatibility fix.
+ [SRU] Backport python3.4 logging module backward incompatibility fix.
--
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:
[SRU] 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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1382607] Re: [SRU] Backport python3.4 logging module backward incompatibility fix.
API breaks are bad, mmmkay. Setting to Critical.
** Changed in: python3.4 (Ubuntu)
Status: New = Triaged
** Changed in: python3.4 (Ubuntu)
Importance: Undecided = Critical
** Also affects: python3.4 (Ubuntu Utopic)
Importance: Critical
Status: Triaged
** Also affects: python3.4 (Ubuntu Trusty)
Importance: Undecided
Status: New
** Changed in: python3.4 (Ubuntu Trusty)
Status: New = Triaged
** Changed in: python3.4 (Ubuntu Trusty)
Importance: Undecided = High
** Changed in: python3.4 (Ubuntu Utopic)
Importance: Critical = High
--
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:
[SRU] Backport python3.4 logging module backward incompatibility fix.
Status in Python:
Unknown
Status in “python3.4” package in Ubuntu:
Triaged
Status in “python3.4” source package in Trusty:
Triaged
Status in “python3.4” source package in Utopic:
Triaged
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1382607] Re: [SRU] Backport python3.4 logging module backward incompatibility fix.
Forgetting myself, dropping to High .. we need this to be fixed really
soon, but it doesn't break EVERYBODY
--
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:
[SRU] Backport python3.4 logging module backward incompatibility fix.
Status in Python:
Unknown
Status in “python3.4” package in Ubuntu:
Triaged
Status in “python3.4” source package in Trusty:
Triaged
Status in “python3.4” source package in Utopic:
Triaged
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1382607] Re: [SRU] Backport python3.4 logging module backward incompatibility fix.
This is fixed upstream in 3.4.2, so it only affects Trusty.
** Changed in: python3.4 (Ubuntu Utopic)
Status: Triaged = Fix Released
--
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:
[SRU] Backport python3.4 logging module backward incompatibility fix.
Status in Python:
Unknown
Status in “python3.4” package in Ubuntu:
Fix Released
Status in “python3.4” source package in Trusty:
In Progress
Status in “python3.4” source package in Utopic:
Fix Released
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1382607] Re: [SRU] Backport python3.4 logging module backward incompatibility fix.
** Changed in: python3.4 (Ubuntu Trusty)
Assignee: (unassigned) = Clint Byrum (clint-fewbar)
** Changed in: python3.4 (Ubuntu Trusty)
Status: Triaged = In Progress
--
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:
[SRU] Backport python3.4 logging module backward incompatibility fix.
Status in Python:
Unknown
Status in “python3.4” package in Ubuntu:
Fix Released
Status in “python3.4” source package in Trusty:
In Progress
Status in “python3.4” source package in Utopic:
Fix Released
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1382607] Re: [SRU] Backport python3.4 logging module backward incompatibility fix.
** Branch linked: lp:ubuntu/trusty/python3.4
--
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:
[SRU] Backport python3.4 logging module backward incompatibility fix.
Status in Python:
Fix Released
Status in “python3.4” package in Ubuntu:
Fix Released
Status in “python3.4” source package in Trusty:
In Progress
Status in “python3.4” source package in Utopic:
Fix Released
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1382607] Re: [SRU] Backport python3.4 logging module backward incompatibility fix.
** Changed in: python
Status: Unknown = Fix Released
--
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:
[SRU] Backport python3.4 logging module backward incompatibility fix.
Status in Python:
Fix Released
Status in “python3.4” package in Ubuntu:
Fix Released
Status in “python3.4” source package in Trusty:
Triaged
Status in “python3.4” source package in Utopic:
Fix Released
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1382607] Re: [SRU] Backport python3.4 logging module backward incompatibility fix.
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) = (unassigned)
** Changed in: python3.4 (Ubuntu Trusty)
Status: In Progress = Triaged
--
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:
[SRU] Backport python3.4 logging module backward incompatibility fix.
Status in Python:
Fix Released
Status in “python3.4” package in Ubuntu:
Fix Released
Status in “python3.4” source package in Trusty:
Triaged
Status in “python3.4” source package in Utopic:
Fix Released
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
