[GRASS-dev] [GRASS GIS] #3392: t.register: encoding error
GRASS GIS
trac at osgeo.org
Sun Aug 13 21:59:30 PDT 2017
#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 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. However this solution can only work with
python2, because in the temporal library now I'm summing bytes with
unicode, that can work only with python2 that does not distinguish between
them.
In python3 this operation raise an error. In general due to bytes
limitation in python3 (mainly there is not format) perhaps we should use
just unicode within the python code...
Therefore I was thinking to replace all the `grass.script.utils` `encode`
function that I added in `grass/lib/temporal` with `decode` to ensure that
everything is unicode. And then replace the `print` function with
`pygrass.messages.Messager` to eventually translate all the python unicode
back to bytes just before printing them to system terminal.
So I'm not sure when is the right moment to transform unicode to bytes.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3392#comment:13>
GRASS GIS <https://grass.osgeo.org>
More information about the grass-dev
mailing list