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

[GRASS GIS]

#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:14 cmbarton]:

 > I fear that this could go on and on, and then pop up somewhere else. Is
 there a cost that actually matters to either using 'ignore' in
 DecodeString and EncodeString or using .replace(u'\ufffd',u'?') in both
 cases?

 Using 'ignore' will '''silently''' ignore conversion errors. The user may
 then try to use the names shown in the GUI and have no clue as to why that
 doesn't work. Using a replacement will alert the user to the fact that the
 name shown is an approximation.

 Using U+FFFD as the replacement (instead of e.g. a question mark) will
 make it easier to locate all of the places which are using str() instead
 of !EncodeString(). "Hiding" these errors will make it harder to fix them.

 str(x) (where x is a Unicode string) is roughly equivalent to
 x.encode(sys.getdefaultencoding(), 'strict'), which in turn is usually
 equivalent to x.encode('ascii', 'strict').

 In most of the places where str() is used, it's debatable whether either
 the 'ascii' encoding or the 'strict' error behaviour are the correct
 choice. In all probability, str() was used in order to duck the issue. But
 if the GUI is to actually work in non-ASCII locales (meaning: the user is
 working with files with non-ASCII names and/or non-ASCII contents; as
 opposed to just having localised menus and labels), then the issues need
 to be addressed.

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