Closed GoogleCodeExporter closed 9 years ago
Actually I don't think it is as simple as encoding to fix it. It's better (I
get colours but everything is semi-transparent).
Original comment by dodgyvi...@gmail.com
on 8 Jan 2014 at 6:17
Hmm, is anyone interested in engaging me on these bug reports or is pyglet dead?
Original comment by dodgyvi...@gmail.com
on 24 Mar 2014 at 3:56
Anyway, please let me know if I can help.
Original comment by dodgyvi...@gmail.com
on 24 Mar 2014 at 11:49
Original comment by useboxnet
on 26 Mar 2014 at 7:45
Yes there is a problem of bytes vs string here.
The problematic lines in pyglet are variants of
a = '%c%c%c%c' % color
In python 2.6 the semantic is : 'convert a 4-tuple of ints to a 4 bytes array'
In python 3.3 the same line does not convey the same semantics.
I couldn't think an equivalent expression with the same semantics in 2 and 3,
or that can be automatically adjusted by 2to3.
But it can be done conditionally for each python:
def color_as_bytes(color):
if sys.version.startswith('2'):
return '%c%c%c%c' % color
else:
if len(color) != 4:
raise TypeError("color is expected to have 4 components")
return bytes(color)
I checked (by including that function in a script) that 2to3 does not modifies
the function.
Also, I tested the patched pyglet and it gives the same image in 2 and 3.
The diff was obtained by
cd working_copy
hg diff pyglet/image/__init__.py >color_pack.diff
and can be applied to a pyglet's checkout by
cd working_copy
hg patch color_pack.diff --no-commit
Original comment by ccanepacc@gmail.com
on 27 Mar 2014 at 5:26
Attachments:
I noticed something similar in:
https://code.google.com/p/pyglet/issues/detail?id=707
Your patch looks good, thanks a lot!
Original comment by useboxnet
on 27 Mar 2014 at 6:34
This issue was closed by revision 023af610e2eb.
Original comment by useboxnet
on 29 Mar 2014 at 12:07
Original issue reported on code.google.com by
dodgyvi...@gmail.com
on 8 Jan 2014 at 6:00