[patch] models.FloatField should be renamed

[adurdin@…]

The behaviour of models.FloatField is inconsistent with its name. In the database backends it is implemented as a fixed-point NUMERIC column, and in Python it returns values of type decimal.Decimal -- which are compatible with each other, but are both incompatible with floating-point numbers. So it should be renamed to DecimalField or something similar that doesn't imply floating-point numbers.

[adurdin@…]

Patch, also renames forms.FloatField (see #2366)

[Jorge Gajon <gajon@…>]

When you are using MySQL as your database backend, you get back Decimal instances for FloatField attributes like you described. But when your database backend is SQLite you get back normal python float numbers. I don't know what happens with PostreSQL

This is inconsistent behavior that should probably be addressed first.

[adurdin@…]

There should definitely be a DecimalField that has nothing to do with floats -- probably also a FloatField for floating-point numbers, if there's a good use case for it.

[adurdin@…]

Separate DecimalField and FloatField db and form fields

[adurdin@…]

New patch: this creates a separate models.DecimalField and models.FloatField, and similar forms.DecimalField and forms.FloatField, and finally, validators.IsValidDecimal and validators.IsValidFloat.

Motivation for this separation comes from the fact that floats lack accuracy to represent decimals (e.g. for monetary values), and decimals are a bad match for floats (e.g. for values with large magnitude exponents). Following this motivation, IsValidDecimal does not accept numbers with a literal exponent, although IsValidFloat does.

This patch also modifies the MySQL and Sqlite database wrappers (I couldn't test against the others), to map DecimalField to NUMERIC, and FloatField to DOUBLE (MySQL) or NUMERIC (Sqlite, which means it's really a string, only collated as a number). The conversions table for MySQL is also changed so that DECIMAL and NEWDECIMAL fields are always returned as strings -- as the default behaviour is to return decimals if possible, or else floats; and we never want a float where we expected a decimal.

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.

[Malcolm Tredinnick]

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.

[anonymous]

What about simply distribuite the module decimal.py in django.utils,
as we already do for, i.e., threading?

try:
   # Only exists in Python 2.4+
   from decimal import Decimal
except ImportError:
   # Import copy of _decimal.py from Python 2.4
   from django.utils._decimal import Decimal

Decimal is just a single python file. See
​http://www.taniquetil.com.ar/facundo/bdvfiles/get_decimal.html#downloading-the-files-separately

[Esaj]

+1 on this. It would be more consistent to map NUMERIC to decimal than to float. We should distribute decimal.py to maintain compatibility with Python 2.3.

[Sergey <rushman@…>]

+1 on distributing decimal.py with Django

[andreas.eigenmann@…]

+1 on this. A decimal type is very important for dealing with money.

[pupeno@…]

+1 on
1) Renaming FloatField to DecimalField (and make it consistently Decimal across databases).
2) Creating a new FloatField that is indeed a floating point value (according to what databases provide).

I would say 1 is essential, 2 is nice to have.

[adurdin@…]

Patch -- implements database FloatField and DecimalField, and supporting fields in oldforms and newforms, with tests.

[adurdin@…]

Added an updated patch against r4439.

• db.FloatField handle only floats, and db.DecimalField handle only decimals.
• oldforms.FloatField and oldforms.DecimalField are the defaults for the db fields and do the Right Thing validation-wise
• newforms.FloatField and newforms.DecimalField ditto; but they also support max_value and min_value arguments à la newforms.IntegerField

This patch includes tests for both the database fields and the form fields.

[Chris Beaven]

Haven't heard from a core developer yet regarding this, so I'll leave it in their hands as to what we're going to do with this issue.

[James Bennett]

#4211 was closed in favor of this.

[Van.Lepthien@…]

• PostgreSql behavior seems to be analogous to that of MySQL. Using FloatField worked with SQLite for floating point values, but 'broke' (i.e., worked properly) when we tried to insert a floating point number into a NUMERIC field.

• SQLite behavior occurs because Sqlite puts whatever value it's passed into the database if it can't do a conversion to the defined type - field types in the table definitions are hints, but they are not strictly enforced. See ​http://www.sqlite.org/faq.html#q3. It's a feature.

• We are developing a system that requires the use of floating point numbers in the database. We probably have to use this patch (which is preferable to an ugly workaround) in order to move forward on our project.

[Malcolm Tredinnick]

(In [5302]) Fixed #2365, #3324 -- Renamed FloatField to DecimalField and changed the code
to return Decimal instances in Python for this field. Backwards incompatible
change.

Added a real FloatField (stores floats in the database) and support for
FloatField and DecimalField in newforms (analogous to IntegerField).

Included decimal.py module (as django.utils._decimal) from Python 2.4. This is
license compatible with Django and included for Python 2.3 compatibility only.

Large portions of this work are based on patches from Andy Durdin and Jorge
Gajon.