Issue solved by Sean Gillies! (http://sgillies.net/)
See http://trac.osgeo.org/geos/ticket/201 and even a snapshot with the fix http://gispython.org/downloads/geos/geos-r2174.tar.gz Thanks man! You rock! []s Luiz Fernando Barbosa Vital On Tue, Aug 26, 2008 at 6:02 PM, Luiz Vital <[EMAIL PROTECTED]> wrote: > 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
