On Tue, 2006-08-29 at 16:46 +0000, Andrew Durdin wrote: [...] > To quote from what I wrote in the ticket: > > > Finally, this patch should work without the decimal module: if the > > decimal module is available, then models.DecimalField? attributes will > > be decimal.Decimal instances; if not, then they will be strings. If the > > user needs to perform arithmetic, then he can call float() and operate > > within the accuracy limits of floats, but it's safer not to convert > > implicitly. > > To which Malcom replied:
If people don't start putting the second 'l' in my name, there's going to be trouble! > > I don't like the implication of the last paragraph of the previous > > comment. It means that every single time you do arithmetic with this > > field, you need to either test that you are running on Python 2.4 or > > call float(). This is a huge burden on the developer. It has to work a > > bit more transparently than that. > > So, which is better to do if the decimal module is not available: is it > better to return a string from a DecimalField, sacrificing convenience > for a guarantee of exact representation, or return a float so that the > user can do arithmetic without hassle? > > I'm of the opinion that the former is better, as it requires the > developer to explicitly take actions that may result in a loss of > information; and for those cases where the developer either needs > floats or doesn't care as much about the accuracy, he can use > models.FloatField, which will consistently return floats. What do > others think? I wish I had an answer for this one, because I can totally see both sides of the situation and I want the best of both worlds. I'm in the process of porting an existing database application I wrote a couple of years ago over to Django, just to see where the hard problems arise. I've hit the same sort of problem, since this app deals with foreign currency exchanges. I'm seriously considering adding my own custom Decimal field, since I can require Python 2.4 for this app. I'd be a bit loathe to add a Python-2.4-only field to Django core, though. Some thoughts about this (adding custom fields)... Extending Django's existing fields to allow custom derivatives is not too hard (there is one two-line change required in base.py). That would allow external apps to register their own field types (and have it appear as the right field type in the model instances). The hard bit is how to integrate this smoothly with the database creation code. If you (or anybody else) has an idea about how to do that easily (a *concrete* idea -- I've already covered "we should do it" :-) ), it would be worthwhile. Then we could allow people to create their own derived fields for their own use; this is particularly easy when the field derives from an existing Django field, a little harder for custom database fields, but still pretty simple to implement the support in core. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" 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-developers -~----------~----~----~----~------~----~------~--~---
