jsonutils.load(s) throwes type error under python3.4

Bug #1515231 reported by Kirill Zaitsev
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
oslo.serialization
Triaged
Medium
Unassigned

Bug Description

Simple script to reproduce:

from oslo_serialization import jsonutils
import six

s = six.StringIO()

jsonutils.dump({'x': 'y'}, s)
s.seek(0)
jsonutils.load(s)

Works as expected under py27, throws TypeError: can't concat bytes to str
under py34

summary: - jsonutils.load(s) throes type error under python3.4
+ jsonutils.load(s) throwes type error under python3.4
Revision history for this message
Davanum Srinivas (DIMS) (dims-v) wrote :
Changed in oslo.serialization:
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Davanum Srinivas (DIMS) (dims-v)
Changed in oslo.serialization:
status: In Progress → Triaged
assignee: Davanum Srinivas (DIMS) (dims-v) → nobody
Revision history for this message
Ben Nemec (bnemec) wrote :

Looking at this a little closer, it seems to me that there is a fundamental problem with this function on Python 3. It allows the user to specify an encoding, but because the file object passed in may or may not have been opened in binary mode, we can't necessarily decode it. If it was opened in normal 'r' mode, the value we get back from read() is already going to be decoded to utf-8.

I think we would need to detect whether the object passed in is giving us bytes or a str and treat it appropriately. If they give us something that results in a utf-8 str and they passed something other than utf-8 as the encoding that would be an error.

Revision history for this message
Martin Kopec (mkopec) wrote :

any progress on this? The issue is still valid:
https://bugs.launchpad.net/tempest/+bug/1806089

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

Other bug subscribers