Pietro wrote: > On Mon, Mar 3, 2014 at 3:59 AM, Hamish [email protected] 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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
