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

GRASS GIS trac at osgeo.org
Tue Nov 15 21:33:13 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:16 cmbarton]:
 > I'm not quite sure what you are suggesting as a solution.
 >
 > Do we need to search through all modules and replace str() with
 str.decode() or utility.DecodeString()?

 Yes.

 > Or is this just needed in a few spots?

 I don't know which cases (if any) should use str(). Someone will need to
 examine them and make a determination based upon how the result will be
 used.

 In most cases, str() is the wrong solution. Correct solutions are:
  * If you know that a specific encoding should be used, use it.
  * If you get to choose the encoding, UTF-8 is preferable, as it can
 encode all Unicode characters.
  * If you don't have any other information, the locale's encoding is the
 best guess.

 Historically, str() was the last resort when you require a byte string. If
 you're passed a Unicode string, the user has screwed up, but using str()
 may be able to recover from it providing the string only contains ASCII
 characters. In Python 3.x, they realised that this was just encouraging
 people to write broken code, and removed implicit byte-string to/from
 unicode-string conversions. Standard library functions and methods which
 expect one or the other will just raise an exception if you pass the wrong
 sort.

 > Or do we just need to change !DecodeString() (and !EncodeString()
 too???) to use string.encode(enc, 'replace').replace(u'\ufffd',u+'\fffd')?

 Both of those functions should just use 'replace' for the error parameter.
 This will replace invalid sequences with U+FFFD when decoding, and all
 unrepresentable characters (including, but not limited to, U+FFFD) with
 '?' when encoding.

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



More information about the grass-dev mailing list