Re: [Django] #34260: models.FloatField documentation doesn't mention that +inf, -inf, and NaN are database-dependent.

[Django]

#34260: models.FloatField documentation doesn't mention that +inf, -inf, and NaN
are database-dependent.
-------------------------------------+-------------------------------------
Reporter: Matt Cooper | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Documentation | Version: 4.1
Severity: Normal | Resolution:
Keywords: floatfield | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Matt Cooper):

Fixed the title, body, and added a new PR.
https://github.com/django/django/pull/16461

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

[Django]

#34260: models.FloatField documentation doesn't mention that +inf, -inf, and NaN
are database-dependent.
-------------------------------------+-------------------------------------
Reporter: Matt Cooper | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Documentation | Version: 4.1
Severity: Normal | Resolution:
Keywords: floatfield | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Mariusz Felisiak):

> In that test case, is the field null=True? In a brand new Django 4.1
project with the following models.py pointing to a SQLite database:

As for me it's a database caveat, and we cannot document all caveats in
Django docs.

> It's also curious that b92ffebb0cdc469baaf1b8f0e72dddb069eb2fb4 (#33954)
explicitly made this unsupported where (at least) PostgreSQL does support
`nan`, `+inf`, and `-inf`. Arguably I'd say that that was a backward
incompatible change with no release note and people may already be
depending on that support. Lack of support for these values is a database-
specific thing.

That's not exactly true. Folks were able to save objects with `nan` but
they were not able to fetch them back from the database, so I don't see
how someone can rely on this behavior.

--
Ticket URL: <https://code.djangoproject.com/ticket/34260#comment:7>

[Django]

#34260: models.FloatField documentation doesn't mention that +inf, -inf, and NaN
are database-dependent.
-------------------------------------+-------------------------------------
Reporter: Matt Cooper | Owner: nobody

Type: | Status: closed

Cleanup/optimization |
Component: Documentation | Version: 4.1

Severity: Normal | Resolution: wontfix

Keywords: floatfield | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Carlton Gibson):

* status: new => closed
* resolution: => wontfix

Comment:

So we have:

> This is not obvious, and much like the "empty string vs null" discussion
in CharField

vs:

> As for me it's a database caveat, and we cannot document all caveats in
Django docs.

I think I agree with the latter here.

The `CharField` `blank`/`null` issue is something that's going to hit
every user, pretty much immediately as they start using Django. It's worth
documenting, and it even merits a whole `kwarg` and special handling in
the field.

In contrast (I think) storing `inf` and `NaN` are more specialised and
advanced use cases. I look at
[https://github.com/django/django/pull/16461/files#diff-
fc688171203d4ce1e42c46f25bddfee5f494b0b1b81258907ff0531c81f2a4aeR1110-R1114
the diff in the PR] and think that it's just not relevant to the vast
majority of users. I think the particular SQLite callout is misplaced
there. **Most though** I expect folks storing these values (as more
specialised and advanced) to be writing tests checking the round-trip
behaviour, in a way that we can't expect of the beginner hitting the
`blank`/`null` issue with CharField.

Floats are troublesome (granted). Maybe there's a cases for an addition to
the [https://docs.djangoproject.com/en/4.1/ref/databases/#databases
Databases doc] with the issue explained for each DB. With the proposed PR,
what conclusion am I to take if I'm on PostgreSQL, or …? — write some
tests and see?

Happy to review such if you wanted to take it on Matt. Pending such, I
think it's a `wontfix`.

--
Ticket URL: <https://code.djangoproject.com/ticket/34260#comment:8>

[Django]

#34260: models.FloatField documentation doesn't mention that +inf, -inf, and NaN
are database-dependent.
-------------------------------------+-------------------------------------
Reporter: Matt Cooper | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Documentation | Version: 4.1
Severity: Normal | Resolution: wontfix
Keywords: floatfield | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Matt Cooper):

Thanks Carlton, I agree that's a better spot for it. I don't have easy
access to most of the supported databases, but I can at least skim their
docs for mention of these special float values.

--
Ticket URL: <https://code.djangoproject.com/ticket/34260#comment:9>

[Django]

#34260: models.FloatField documentation doesn't mention that +inf, -inf, and NaN
are database-dependent.
-------------------------------------+-------------------------------------
Reporter: Matt Cooper | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Documentation | Version: 4.1
Severity: Normal | Resolution: wontfix
Keywords: floatfield | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Carlton Gibson):

> I don't have easy access to most of the supported databases...

If you can make a stab at SQLite, Postgres, and MySQL (if you have that)
we are^here meaning Mariusz is :)^ quite accustomed to helping with the
Oracle bit.

--
Ticket URL: <https://code.djangoproject.com/ticket/34260#comment:10>

[Django]

#34260: models.FloatField documentation doesn't mention that +inf, -inf, and NaN
are database-dependent.
-------------------------------------+-------------------------------------
Reporter: Matt Cooper | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Documentation | Version: 4.1
Severity: Normal | Resolution: wontfix
Keywords: floatfield | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Tim Graham):

The [https://github.com/django/django/pull/16483 proposed addition] to the
database docs looks unnecessary, particularly because the form field
disallows these values. The documentation for the model `FloatField`
begins "A floating-point number..." and gives no indication that `NaN` and
`inf` (non-numbers) are supported.

--
Ticket URL: <https://code.djangoproject.com/ticket/34260#comment:11>

[Django]

#34260: models.FloatField documentation doesn't mention that +inf, -inf, and NaN
are database-dependent.
-------------------------------------+-------------------------------------
Reporter: Matt Cooper | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Documentation | Version: 4.1
Severity: Normal | Resolution: wontfix
Keywords: floatfield | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Carlton Gibson):

Yes, sorry Matt — thanks for the hustle, but I have to agree. This is
right into the woods, for something which most users will never hit.

A model and a form:

{{{
from django import forms
from django.db import models

class FloatModel(models.Model):
number = models.FloatField(null=False)

class FloatForm(forms.ModelForm):
class Meta:
model = FloatModel
fields = ['number']
}}}

Then:

{{{
>>> from ticket_34260.models import FloatModel, FloatForm
>>> form = FloatForm({"number":float("inf")})
>>> form.is_valid()
False
>>> form.errors
{'number': ['Enter a number.']}
>>> form = FloatForm({"number":float("nan")})
>>> form.is_valid()
False
>>> form.errors
{'number': ['Enter a number.']}
>>> form = FloatForm({"number":float("-inf")})
>>> form.is_valid()
False
>>> form.errors
{'number': ['Enter a number.']}
}}}

I appreciate you **can** work around the form layer but I think at that
point we come back to Mariusz' ''we cannot document all caveats in Django
docs''.

Likely this ticket will serve folks searching this in the future, so it's
not all for naught.

--
Ticket URL: <https://code.djangoproject.com/ticket/34260#comment:12>