[GRASS-dev] Re: [GRASS GIS] #1488: v.in.dxf wrapper not working

GRASS GIS trac at osgeo.org
Sat Nov 12 07:11:06 EST 2011


#1488: v.in.dxf wrapper not working
-------------------------+--------------------------------------------------
 Reporter:  cmbarton     |       Owner:  grass-dev@…              
     Type:  defect       |      Status:  new                      
 Priority:  normal       |   Milestone:  7.0.0                    
Component:  wxGUI        |     Version:  svn-trunk                
 Keywords:  v.in.dxf     |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------

Comment(by glynn):

 Replying to [comment:3 cmbarton]:

 > AFter looking into this, it appears that it is NOT an OSX 10.7 issue but
 a bug. However, for some reason, the bug only shows up on my OSX 10.7 box.
 >
 > The !DecodeString method in util.py calls string.decode()
 >
 > However, the string module does not have a "decode" method in Python 2.6
 or 2.7.

 In this context, "string" is the name of !DecodeString()'s parameter, not
 the name of a module. It is presumably meant to be a string; since 2.2,
 Python strings have had a .decode() method
 ([http://docs.python.org/library/stdtypes.html#str.decode link]).

 > This is what is causing the error. What is this supposed to be doing?

 Decoding the string (converting from a sequence of bytes to a sequence of
 Unicode characters).

 > The value that string.decode() is supposed to be decoding is "mac-roman"
 on my machine.

 The argument is the name of the encoding; the string on which the
 .decode() method is called is the string which is decoded. So
 string.decode('mac-roman') converts the variable "string" from a sequence
 of bytes in the "mac-roman" encoding to a Unicode string.

 Mac-roman is a unibyte encoding (one byte equals one character), so it
 shouldn't be possible for the decoding to fail (you just get mojibake if
 the string isn't actually in the mac-roman encoding). But the traceback in
 comment:2 indicates that the UTF-8 encoding is being used. UTF-8 is a
 multibyte encoding which reserves specific bytes for specific positions
 (e.g. 0-127 are single-byte characters, 192-255 are used for the first
 byte of a multi-byte character, 128-191 are used for subsequent bytes of a
 multi-byte character). If a byte appears in the wrong position, you get an
 error.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1488#comment:4>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list