[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