On Tue, 2008-11-25 at 01:01 -0800, Ulf Kronman wrote: [...] > You also said that you could see some interesting behaviour on Apache, > and my (maybe stupid) question was meant to be if that somehow could > affect the Django template engine.
The "template engine", as you keep calling it, is just a set of functions calls inside Django's modules. It's nothing special. What you are seeing is some kind of parsing being affected by the locale -- that will happen throughout Django consistently. I suspect if you ran Django's test suite, you would see consistent failures because of this (might be interesting to do, if you have the time and motivation, since it would pick up what other functions are locale-dependent in there that we may have overlooked). My throw-away "interesting" remark was because if you change the locale for a process that might be dealing with multiple applications in different threads, they will *all* see the change. Possibly mid-operation. And not all of those applications might be Django. Basically, you can't call setlocale() in a multi-threaded environment unless it's the very first thing you do and then it never changes. So it's not an option for something like Django. This isn't anything Apache-specific. It's just a fact of life with the way setlocale() works at the C level (running the same process in multiple locales simultaneously wasn't a design feature). All I was trying to do was warn against thinking setlocale() was a solution to any problem. I seem to have accidentally made a mountain out of a molehill there and confused things more than helped. So forget about it. > > so it's quite believable that if your system is set up > > to process things in the Swedish locale by default, that is what will be > > happening. > > I tried to change my OS settings to use point as decimal delimiter, > but it didn't help, so I presume that there is something else than the > OS settings that is telling floatformat to expect comma as decimal > delimiter. Have a look at the code: django.template.defaultfilters.floatformat() doesn't care about separators. It passes everything off to Python to do any parsing. However, now that I look back at your original report, I notice that you didn't actually give a lot of details of the error. Just the final line of the exception, which is equivalent to saying "I'd like to report a car accident" and then not mentioning the location. You will have a full traceback there (if you're seeing this in Django's debug screen, switch to cut-and-paste view before trying to paste the traceback). It would be interesting to see the exact line the error occurred on and the type of exception that was raised. The int() function call is used both in floatformat() itself and as part of the Decimal() class, so it's not obvious which line if the problem. Re-reading that now, I also see that it's got nothing to do with the float() call, since that isn't mentioned. My brain apparently got stuck on the name of the filter. The exception is reported for int(). So whilst everything we've been talking about in previous messages is true, it's quite possibly not particularly relevant. 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 -~----------~----~----~----~------~----~------~--~---
