[GRASS-dev] [GRASS GIS] #3392: t.register: encoding error

[GRASS GIS]

#3392: t.register: encoding error
--------------------------+---------------------------------
  Reporter:  mlennert     |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  7.2.3
 Component:  Temporal     |    Version:  svn-trunk
Resolution:               |   Keywords:  t.register encoding
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+---------------------------------

Comment (by mlennert):

 Replying to [comment:35 glynn]:
 > Replying to [comment:33 mlennert]:
 > > Replying to [comment:32 glynn]:
 > > > The functions in grass.script should **never** return unicode. That
 module reads the contents of files (which are sequences of bytes) and the
 output from processes (again, sequences of bytes).
 > >
 > > Is this true for translated module messages as well ?
 >
 > Yes. Anything which originates as a byte string (e.g. output from
 commands, contents of files) should be kept as a byte string. Anything
 which (for whatever reason) originates as a unicode string should be
 encoded at the earliest opportunity.

 Thanks for the explanations, Glynn. However, I'm really a bit lost in this
 whole discussion. One example: I always thought that unicode was an
 abstract representation, but that in practice a unicode string was always
 encoded in some encoding, with Python 3 using UTF-8 by default. Or does
 Python 3 really store the actual unicode code points ?

 And what would it take for our C code to be converted to unicode ?

 I think we need two things to go further on this:

 * Write up (or link to) a clear explanation of the unicode issues in
 Python, in the specific context of GRASS GIS with links between Python and
 C code, so that we make sure we have a common understanding.
 * Make it one of our priorities, probably better after the 7.4 release, to
 sort things out in a coherent and clearly documented manner (including
 best practice guide to developers), in order to avoid this issue bothering
 us for years to come.

 Moritz

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