[AG-DEV] AccessGrid setting locale?
c.willing at uq.edu.au
Mon Apr 4 17:50:16 CDT 2011
On 05/04/2011, at 1:29 AM, Andrew Ford wrote:
> Hi Chris,
> That makes sense, and I don't know of any other way to fix language
> issues like that, but I would suggest that that call be moved
> somewhere else if possible. Like the python docs say, it seems
> inappropriate for a library to be setting the locale, and when you
> just do the import agversion/agversion.select() to e.g. use the IW
> classes to query or control the venue client, AG is effectively
> being used as a library. Could that call be moved to somewhere like
> when the GUI is set up? I'm not familiar enough with the AG codebase
> to say, but it makes more sense to me to be somewhere like that
> rather than in the very high-level general code like Toolkit.py is.
I'll raise it with Tom at the next Townhall - maybe he can think of
some better place to put it.
I remember trying a few less-central places to include it but the
logical candidates I tried at the time didn't work. Also I think there
was more than just the gui issue i.e. printing of jabber timestamps. I
vaguely recall a second issue - I think a time field in a particular
format was being used by some crypto code somewhere - which depended
on the locale setting. The quick fix was to centralise setting the
locale; I guess no one has had the time to find a better place for it
Could you add a bugzilla entry for this? Then there's less chance it
will be forgotten ...
> 2011/4/1 Christoph Willing <c.willing at uq.edu.au>
> On 02/04/2011, at 6:04 AM, Andrew Ford wrote:
> I noticed some interesting effects in a C++ application I'm
> developing that calls various AG functions via the Python API. My
> app also uses wxWidgets, and when I was experimenting with its
> logging functions, I noticed that the timestamp format it uses
> changes after I call a standard import agversion and
> agversion.select(3). I looked a bit for any locale setting AG does
> and found locale.setlocale(locale.LC_ALL, 'C') in Toolkit.py.
> Commenting this line out prevents the timestamp (presumably the
> associated locale settings as well) from changing; I haven't tested
> whatever effect it may have on the venue client. I'm curious as to
> what the rationale for this call is, as even the python docs (http://docs.python.org/library/locale.html
> ) say it is not necessarily a good idea to set this in a context
> like this ("It is generally a bad idea to call setlocale() in some
> library routine, since as a side effect it affects the entire
> program.") Any input on this issue would be great.
> It was added so that non-english language users could use the
> toolkit. I believe the original issue was incorrect time stamping in
> the chat window but there was also some other side effect (which I
> can't recall right now) that was fixed by setting the locale.
> If there's a better way (than setting the locale like that) to fix
> the language issue then lets do it ...
> Christoph Willing +61 7 3365 8316
> QCIF Access Grid Manager
> University of Queensland
Christoph Willing +61 7 3365 8316
QCIF Access Grid Manager
University of Queensland
More information about the ag-dev