[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:7 cmbarton]:
 > After a bit of testing, using 'ignore' works, but 'replace' creates
 further errors down the line
 >
 {{{
 'ascii' codec can't encode character u'\ufffd' in position
 0: ordinal not in range(128)
 }}}

 > Unless there is a compelling reason to do otherwise, I suggest using
 'ignore'.

 One option is:

 {{{
 string.decode(enc, 'replace').replace(u'\ufffd',u'?')
 }}}

 This will replace unconvertible sequences with question marks, which
 provides a clue that the string is an approximation (this is how e.g. "ls"
 behaves if it needs to list filenames which contain sequences which cannot
 be converted according to the current locale).

 However, if the !EncodeString method is changed to also use 'replace', the
 U+FFFD characters can be left alone:
 {{{
 > 'hello\xc1world'.decode('utf-8', 'replace')
 u'hello\ufffdworld'
 > 'hello\xc1world'.decode('utf-8', 'replace').encode('ascii', 'replace')
 'hello?world'
 }}}


 > Also, since the "string" module is imported, using "string" as a
 variable name in a method so as to produce a code line like
 >
 > string.decode(enc)
 >
 > seems potentially confusing to those reading the code at least, and
 potentially to the program. Maybe the variable should be changed to "str"
 or something along that line.

 "str" is the actual name of Python's native string type, and of its
 constructor, str().

 It doesn't really matter if a parameter or local name shadows a global or
 built-in name, so long as you don't need to actually use the name being
 shadowed within the function.

 For complex functions, it's easy to forget that a built-in name is being
 shadowed, resulting in obscure errors (e.g. "'str' object is not callable"
 if you try to use the map() function when "map" is actually a local
 variable containing a string). But !EncodeString is only 7 lines.

 Also, utils.py only imports the "string" module for the join() and split
 functions, which are used in normalize_whitespace(). Presumably it could
 just use the .join() and .split() methods, i.e.:
 {{{
 return ' '.join(text.split())
 }}}

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