bytes regex matching issue in font_manager.py around 1283 (line number) #1767

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
5 participants
Owner

mdboom commented Feb 20, 2013

for match in _fc_match_regex.finditer(output):

the 'output' is a byte array, but expected is string runtime type-error,

i think this issue might already have been raised. I am using python3-mapltplotlib-tk backend on fedora 18. I am not sure if it is fixed or not.

THE FIX(atleast for me):
I change the above line to (I changed the byte array to utf-8 string)
for match in _fc_match_regex.finditer(output.decode("utf-8")):
and I am able to plot.No type-error

Owner

mdboom commented Feb 20, 2013

I've attached an alternative fix that just changes the regex expression to be a byte string.

Member

dmcdougall commented Feb 20, 2013

@fedvasu Does @mdboom's solution fix the problem?

fedvasu commented Feb 21, 2013

@dmcdougall I will submit the patch link to fedora maintainers and we'll test there, I think, it should fix the issue.

Member

dmcdougall commented Mar 23, 2013

@fedvasu Did you get any constructive feedback upstream regarding this? This is a simple change, but the Python 3 Travis build didn't complete. Can anyone confirm whether this is py3 safe?

Owner

mdboom commented Mar 25, 2013

The Python 3 Travis build looks to be a false positive. This should be Python 3 safe (and works for me locally). subprocess.Popen returns bytes on both 2 and 3, so the regex over it should be bytes as well.

Contributor

tomspur commented Apr 3, 2013

The alternative fix doesn't work for me, but the output decoding to utf-8 does.

That's because later on you check if the bytes extension is in the set of string extensions, which always fails. With the output decoding fix, both are always strings and that passes too.

I don't know, how to add a fix for this directly, so I sent another pull request in issue #1879.

Member

pelson commented Apr 18, 2013

I'm closing this PR as it is a duplicate (in problem space, not in solution) to #1879. I'm not closing this PR because it is less good than #1879 - simply because only one PR is needed (whatever the solution).

Cheers,

@pelson pelson closed this Apr 18, 2013

@mdboom mdboom deleted the mdboom:fc-match-regex branch Nov 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment