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
-~----------~----~----~----~------~----~------~--~---

Reply via email to