[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.2
 Component:  Temporal     |    Version:  svn-trunk
Resolution:               |   Keywords:  t.register encoding
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+---------------------------------

Comment (by mlennert):

 Replying to [comment:13 zarch]:
 > Hi Anna,
 >
 > Replying to [comment:12 annakrat]:
 > > The problem mostly comes from calling gisenv function from
 script.utils which returns unicode. This was done some time ago to make
 the library Python3 compatible. So we eventually need to move towards
 unicode, but to have a quick fix for the release, we can keep the temporal
 library using bytestrings.
 >
 >
 > I didn't have time to test your solution yet.
 >
 > Actually for me it is still not clear where should we use `unicode` and
 where `bytes`.
 > Do you have some general guidelines?
 >
 > In the changes that I did, I transformed everything in bytes, and now
 the tests that I added to reproduce the ticket's error are passing, so the
 ticket is "theoretically" fixed.

 Using only the temporal_encode.patch​ you uploaded this morning and
 applying it to a fresh svn tree, I still get the same error with
 t.register and the weird output of t.info and t.topology. t.remove and
 t.unregister do not throw an error when run in that order, but when I run
 t.unregister before running t.remove I get the same error.

 Also, there is a lot of code such as this:


 {{{
  print("nsres_min=" + encode(self.get_nsres_min()))
  print("nsres_max=" + encode(self.get_nsres_max()))
  print("ewres_min=" + encode(self.get_ewres_min()))
  print("ewres_max=" + encode(self.get_ewres_max()))
 }}}

 and


 {{{
 string += encode(id) + fs + encode(start) + fs + encode(end)
 string += fs + encode(stats["mean"]) + fs + encode(stats["min"])
 string += fs + encode(stats["max"]) + fs + encode(stats["mean_of_abs"])
 string += fs + encode(stats["stddev"]) + fs + encode(stats["variance"])
 string += fs + encode(stats["coeff_var"]) + fs + encode(stats["sum"])
 string += fs + encode(stats["null_cells"]) + fs + encode(stats["cells"])
 }}}

 All the info transformed to strings here are numeric values that come from
 within the module. I don't think we should ever encode such values, or ?

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