Malcom, I understand your point, I really didn't know setlocale would be so poisonous, for now on I'm avoiding using it!
But locale format doesn't make any sense in a WKT representation, since it's simply spits data that is in a wrong format, so useless. About people talking of thread safety... even in the official python docs they talk abou this! http://docs.python.org/lib/module-locale.html ...setlocale() is not thread safe on most systems. Applications typically start with a call of... Thanks for the reply. Luiz Fernando Barbosa Vital ZNC Sistemas On Tue, Aug 26, 2008 at 2:26 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > On Tue, 2008-08-26 at 11:01 -0300, Luiz Vital wrote: >> Hello all, >> >> I've being using geodjango since it was in a branch in a number of >> projects, and in one project specifically I was getting and >> OGRGeometry Exception intermitently. >> >> After debuging the code I noticed that de wkt string generated from >> geometries were taking the current locale into account, thus raising >> the Exceptions due to a bad WKT string representation. Here goes an >> example: >> >> >>> import locale >> >>> from django.contrib.gis.geos import Point >> >>> p = Point(-45.23, -23.15) >> >>> p.wkt >> 'POINT (-45.2299999999999969 -23.1499999999999986)' >> >>> locale.getlocale() >> (None, None) >> >>> locale.setlocale(locale.LC_ALL, ('pt_BR','UTF-8')) >> 'pt_BR.UTF8' >> >>> p.wkt >> 'POINT (-45,2299999999999969 -23,1499999999999986)' >> >> Notice de comma "," for decimal separator in the last output. >> >> It must be something in the GEOS C library and in this case should be >> fixed there, but maybe it should be avoided reseting de locale before >> calling the C routine and restoring the locale to what it was just >> after. >> >> I think the reason this problem was not always happening is related to >> the some setlocale thread safety issue. > > People keep saying "thread safe" when they talk about setlocale(), but > the real point is that it simply has global effect. It's not local to > the current thread -- so there's no relevance in any thread safeness, > since it's not intended to be per-thread. > >> >> Any thoughts / tips on > > Yes, don't do that. > > It will affect things right down to the C library level and if the > library isn't designed to intentionally counteract those affects (which > is sometimes a library design bug and you could consider filing a bug > after researching if they've already considered this or not) you need to > make sure you play nicely with the library. > > Note that I say "sometimes" because it could be that it is only the > printed output which is affected here, in which case it's completely > correct: the string output *should* be presented in the locale you asked > for. However that can have unintended side-effects if, e.g, that is the > same format used to pass parameters to the database and the server isn't > expecting things in the same format. > > Python's setlocale() is unfortunately not particularly useful for > applications runnings multiple threads of execution. There are just too > many unintended side-effects. > > Regards, > Malcolm > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
