search

thegooglecodearchive / editra-plugins

Automatically exported from code.google.com/p/editra-plugins
0 stars 1 forks source link

[pystudio] Unicode decode error #192

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Was debugging auibook.py in Editra and got this error when a breakpoint was 
hit. This occurred in the latest 0.4 release.

*** Tue Sep 20 18:02:32 2011 ***
Traceback (most recent call last):
  File "wx\_core.pyo", line 16431, in <lambda>
  File "build/bdist.macosx-10.3-fat/egg/PyStudio/Debugger/VariablesLists.py", line 157, in UpdateVariablesList
  File "build/bdist.macosx-10.3-fat/egg/PyStudio/Debugger/VariablesLists.py", line 146, in PopulateRows
  File "build/bdist.macosx-10.3-fat/egg/PyStudio/Debugger/VariablesLists.py", line 371, in expand_item
  File "build/bdist.macosx-10.3-fat/egg/PyStudio/Common/PyStudioUtils.py", line 67, in get_unicodevalue
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal 
not in range(128)

Original issue reported on code.google.com by CodyPrec...@gmail.com on 20 Sep 2011 at 11:09

GoogleCodeExporter commented 9 years ago 
Does it happen every time you debug auibook.py? Are you debugging just that one 
file or Editra as a whole? If the latter, is it possible for you to produe a 
cut down example?

Thanks,
Mike

Original comment by rans1...@gmail.com on 29 Sep 2011 at 1:03

GoogleCodeExporter commented 9 years ago 
Hi,

In get_unicodevalue its apparent what happened. It is defaulting to ascii in 
the except clause. Does winpdb actually send strings with a byte order mark 
(BOM) on them? This would kind of surprise me since BOMs are usually only found 
at the beginning of a file to indicate a UTF encoding. If its not sending the 
BOM then the checks for the byte order mark will always fail resulting in 
'ascii' being used to decode (which is the same as calling unicode(val)).

Would suggest either using ed_txt.DecodeString(string) to get the unicode 
version or replacing the BOM check with a list of common encodings falling back 
to latin1 when others fail.

Original comment by CodyPrec...@gmail.com on 29 Sep 2011 at 4:12

GoogleCodeExporter commented 9 years ago 
Should be fixed in current SVN.

I removed the code that was calling eval as I couldn't see why it was doing 
that and in most cases the objects being passed into the method were already 
unicode.

Tested while debugging a variety of scripts and didn't notice any issues.

Please verify the changes if you get a chance.

Original comment by CodyPrec...@gmail.com on 6 Oct 2011 at 10:49