#35284: PositiveIntegerField description is confusing
-------------------------------------+-------------------------------------
Reporter: Jon Ribbens | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Documentation | Version: 5.0
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Jon Ribbens):
Replying to [comment:10 Natalia Bidart]:
> Hey Jon, I beg to differ. Both bcail and myself are answering to your
argument: while there is ''not'' a proposal to deprecate allowing 0 in the
field, the sentence warns the users about potential unexpected outcomes.
It's easy to assume that a `PositiveIntegerField` would not allow 0, so
the note in the docs is making it clear that 0 ''is allowed'' and it will
be for the foreseeable future due to the backward compatibility goal.
Sorry, that just confirms that you're missing what I'm trying to say. As I
said right at the start, the change to explicitly say that zero is allowed
was clearly a good and beneficial change. Everyone is agreed on that. But
the sentence I'm suggesting be removed, which says that this is "for
backward compatibility reasons", ''doesn't'' make it clear that this will
behaviour will remain "for the foreseeable future". That's my entire
point!
Actually it conveys the precise opposite information, it suggests that it
is foreseen that in the future, the behaviour may change so that zero will
not be accepted, and so if you want to store zeroes you should not be
using this field type. It is saying "we don't think this field should
accept zeroes, but we haven't been able to fix it yet because of backwards
compatibility considerations, so that change is still on the to-do list".
That's why I think the wording should change, because it does ''not''
convey the message you think it does (which is not, frankly, a message
that needs conveying in the first place).
Would anyone be interested in a patch to make it so that it was
`PositiveIntegerField(allow_zero=True)` (and similarly for the other two
"Positive" fields)? i.e. it maintains backwards compatibility, but the
programmer can choose whether they want zeroes allowed or not? I might
find that an interesting little project, but only if there was a
reasonable chance the patch would get accepted (I was expecting this one
to be a shoo-in!)
--
Ticket URL: <https://code.djangoproject.com/ticket/35284#comment:11>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018e2ed7ebe2-d2f8f35f-30cd-4aa0-8e4c-04aabc8028ca-000000%40eu-central-1.amazonses.com.
