[GRASS-dev] [GRASS GIS] #2727: wxGUI startup: 'ascii' codec can't decode byte 0xc3 in position 15: ordinal not in range(128)

GRASS GIS trac at osgeo.org
Sat Aug 29 18:07:52 PDT 2015


#2727: wxGUI startup: 'ascii' codec can't decode byte 0xc3 in position 15: ordinal
not in range(128)
--------------------------+-------------------------
  Reporter:  mlennert     |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  7.0.2
 Component:  wxGUI        |    Version:  svn-trunk
Resolution:               |   Keywords:  encoding
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-------------------------

Comment (by glynn):

 Replying to [comment:2 mlennert]:

 > It seems to me that we need to fundamentally rethink encoding handling,
 but that up to now encoding issues have been 'fixed' one by one without
 getting at the underlying weaknesses. But maybe I'm completely wrong in
 that understanding...

 When issues arise due to unicode strings being passed to functions
 expecting byte string, the issue is normally fixed by adding an encode()
 call in the caller. But to catch other such cases, it would help to also
 modify the callee to explicitly check (e.g. via an assert statement) that
 the value is a byte string rather than a unicode string.

 An explicit check will catch cases where the passed-in string happens to
 be convertible to ASCII. Relying upon Python raising an UnicodeError
 doesn't help much when most of the strings being passed around are
 convertible to ASCII.

 Ideally, such checks should be added at the lowest point of the call
 chain, in order to catch all possible routes to the point where the error
 occurs.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2727#comment:8>
GRASS GIS <https://grass.osgeo.org>



More information about the grass-dev mailing list