[Django] #32118: db.models.FloatField name misleading

9 views
Skip to first unread message

Django

unread,
Oct 18, 2020, 8:57:37 AM10/18/20
to django-...@googlegroups.com
#32118: db.models.FloatField name misleading
-------------------------------------+-------------------------------------
Reporter: | Owner: nobody
mangelozzi |
Type: New | Status: new
feature |
Component: Database | Version: 3.1
layer (models, ORM) |
Severity: Normal | Keywords: Fields
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
In the DB world the difference between `float` (4 bytes) and `double` (8
bytes) is arguably common. However Django calls a `double` a `float`. I
would imagine it would be very hard to add a `DoubleField` and make
`FloatField` the normal 4 byte float due to legacy. Although not ideal how
about adding a `SmallFloatField` or `RealField` some other name to allow
users to create a 4 byte floats?

PostgresQL calls 4 byte float a `real`, and a 8 byte float a `double
precision`
https://www.postgresql.org/docs/9.1/datatype-numeric.html

Mysql calls 4 byte float a `float`, and a 8 byte float a `double`
https://dev.mysql.com/doc/refman/8.0/en/floating-point-types.html

Note: People cite "space is cheap", but this is not always the case, and
depending on the situation there are real practical savings.

--
Ticket URL: <https://code.djangoproject.com/ticket/32118>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Oct 18, 2020, 8:59:55 AM10/18/20
to django-...@googlegroups.com
#32118: db.models.FloatField name misleading
-------------------------------------+-------------------------------------
Reporter: mangelozzi | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 3.1
(models, ORM) |
Severity: Normal | Resolution:
Keywords: Fields | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by mangelozzi:

Old description:

> In the DB world the difference between `float` (4 bytes) and `double` (8
> bytes) is arguably common. However Django calls a `double` a `float`. I
> would imagine it would be very hard to add a `DoubleField` and make
> `FloatField` the normal 4 byte float due to legacy. Although not ideal
> how about adding a `SmallFloatField` or `RealField` some other name to
> allow users to create a 4 byte floats?
>
> PostgresQL calls 4 byte float a `real`, and a 8 byte float a `double
> precision`
> https://www.postgresql.org/docs/9.1/datatype-numeric.html
>
> Mysql calls 4 byte float a `float`, and a 8 byte float a `double`
> https://dev.mysql.com/doc/refman/8.0/en/floating-point-types.html
>
> Note: People cite "space is cheap", but this is not always the case, and
> depending on the situation there are real practical savings.

New description:

In the DB world the difference between `float` (4 bytes) and `double` (8
bytes) is arguably common. However Django calls a `double` a `float`. I
would imagine it would be very hard to add a `DoubleField` and make
`FloatField` the normal 4 byte float due to legacy. Although not ideal how

about adding a `SmallFloatField`, or `RealField`, or some other name to
allow users to create a 4 byte floats, or raise awareness to when they use
a `FloarField`, it may not be what they expect?

PostgresQL calls 4 byte float a `real`, and a 8 byte float a `double
precision`:
https://www.postgresql.org/docs/9.1/datatype-numeric.html

Mysql calls 4 byte float a `float`, and a 8 byte float a `double`:
https://dev.mysql.com/doc/refman/8.0/en/floating-point-types.html

Note: People cite "space is cheap", but this is not always the case, and
depending on the situation there are real practical savings.

--

--
Ticket URL: <https://code.djangoproject.com/ticket/32118#comment:1>

Reply all
Reply to author
Forward
0 new messages