[GRASS-dev] Character encoding of module i.atcorr files

[Glynn Clements]

Pietro wrote:

> On Mon, Mar 3, 2014 at 3:59 AM, Hamish hamish_b at yahoo.com wrote:
> 
> and lib/python/pygrass/functions.py …
> 
> as for functions.py, hooking into G_legal_filename() would
> be best
> 
> done in r59180.

FWIW, if you want to avoid using a C function, it's trivial to
re-implement G_legal_filename() in Python. In particular, *any*
character >= 127 is invalid.

> Personally, I would prefer it if source code was 7-bit clean.
> 
> Me too. Not sure how to deal with non-ASCII chars in people’s names though.

If they're moderately well known, it shouldn't be hard to find out the
standard romanisation.

> I don’t see the reason to avoid source code in utf-8, at least on
> python files, in particular when it is explicitly declare in the file
> header like this (as in PEP 0263):
> 
> # -*- coding: utf-8 -*-

Source code doesn't just have to work with the interpreter. It needs
to work with text editors, web browsers, revision-control systems,
printers, etc. Some of those understand coding cookies, some don't.

The main problem with coding cookies is that software which
(explicitly or implicitly) converts between encodings typically leaves
the cookie unchanged. Which is why libraries such as chardet typically
treat coding cookies as little more than a hint or fallback.

-- 
Glynn Clements <glynn at gclements.plus.com>