[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 cmbarton):

 Replying to [comment:11 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).

 This works fine.

 >
 > However, if the !EncodeString method is changed to also use 'replace',
 the U+FFFD characters can be left alone:
 Changing !EncodeString to use replace does not work. There is still the
 same error reported above.

 > {{{
 > > '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())
 > }}}

 This seems like a good idea to simplify the code some.

 Michael

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