On Sat, 2008-11-29 at 00:37 -0800, Ulf Kronman wrote:
> Hi, I'm back to report that I have found the cause and a temporarily
> solution to my problem.
>
> First of all; thanks to Malcolm and Karen for trying to help me out,
> even if I didn't give a lot of detail on the problem in the first
> round. The reason was that I was frustrated and tired late in the
> night when sending the first desperate help call.
>
> > 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.
>
> OK, Malcolm, now I have spotted the _exact_ location of the "code
> crash", and it is at the point where I send my SQL statement off to
> pymssql and get it returned (the exact point is actually when it is
> returned).
>
> This is my code to pymssql:
> cur = con.cursor()
> cur.execute(str_query)
> lst_result = cur.fetchall()
>
> And the result returned in the variable lst_result is the following:
>
> [(Decimal("27164771"), 27, 16, 7.77128, 9.2557200000000002, 2006,
> 'Quantum dynamics of a d-wave Josephson junction', 3, 30.0,
> '000234546300030', 17.601243339253998, '@', 7)]
>
> Do you notice the Decimal("27164771")? This is the ID of the record in
> question and the value is stored as a longint in our MS SQL database.
>
> It seems to me that when the Python renderer sees the Decimal() call,
> it goes and fetches my OS locale, which calls for Swedish decimal
> commas instead of US decimal points.
This doesn't seem to be the case from looking at the source. The decimal
module in Python is purely Python code and it doesn't call any of the
locale functions (it would be a bug if it did, since library's cannot
call those). It also only uses a period as the decimal point separator
for input and the __str__ method of the Decimal class only uses a period
as the separator for output.
I'd personally be a little suspicious of what the database backend is
doing. Is the type of your id column really something that can only be
represented by a Decimal() class? Because if it's an integer, the db
backend should be returning an integer there (that's a secondary bug,
but it makes me suspicious about what else is going on).
Try comparing the output of locale.localeconv() before and after you
make the call to the database, for example. It shouldn't change and
everything should be operating in the C locale (since the external
locale of your system isn't applied unless something calls
locale.setlocale(locale.LC_ALL, '')). I could imagine some code that
tries to be "helpful" and changes the locale for whatever reason and
messes everything else up.
Another thing you can try is removing the call to the database
altogether and just hard-coding the return result for a little while
(including the Decimal bit). Maybe you can't do that directly in your
code (if you're doing an insert), but it should be straightforward to
create a small view that reads from the database and applies
floatformat() and explodes and reads from a tuple containing exactly the
same data, applies floatformat and .... (fill in the blank). The second
case should be done on a separate run from the first one (don't touch
the database at all in the second case), since we don't want the
database code touching the locale setting, if that's what is happening.
In fact, ideally, don't even use Django at all here. You know the line
of code that is failing, so you can probably just write a 10 line
program that reads something from the database and then executes a
similar line and make sure it fails similarly. Then do the same thing
but without the database (just hard-coded data).
At the moment, it looks very much to me like something in this
non-Django code is messing up your system environment. The decimal
module in Python is very portable and nothing in it or Django attempts
to change the running locale (which means it will always be 'C'). I
think you're looking in the wrong place for the bug at the moment --
where the traceback is raced is a consequence of the problem, not the
source.
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
-~----------~----~----~----~------~----~------~--~---
