#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 Natalia Bidart):
Replying to [comment:11 Jon Ribbens]:
> [...] 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!
I fully understand your point, but I disagree. Deprecation notices are
documented quite clearly and they follow a strict procedure of when they
can be introduced and when they occur. So until these docs explicitly say
"Deprecated in Django version X.Y", the value `0` will be allowed for the
foreseeable future.
> 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".
I understand that this is how ''you'' read the sentence, but we disagree
on what it means. Saying ''The value 0 is accepted for backward
compatibility reasons.'' is just an **explanation**, is not a heads-up
that is going to be changed (as mentioned before, deprecation notices are
handled quite differently). The sentence only explains **why** it is the
way it is. Otherwise we'd regularly get new tickets saying
"PositiveIntegerField should not accept 0 because 0 is not a positive
number". In order to manage expectations from Django users, the
clarification is there saying "we know this is weird but it's there for a
reason".
> 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!)
You are welcomed to share the idea with the Django community, following
the [https://docs.djangoproject.com/en/stable/internals/contributing/bugs-
and-features/#requesting-features the documented guidelines for requesting
features]. I, personally, don't think this is worth adding since by just
using a custom and trivial validator (or just using `MinValueValidator`)
the need of not allowing `0` in the field is solved, and in my experience,
allowing for 0 is the less surprising semantic.
--
Ticket URL: <https://code.djangoproject.com/ticket/35284#comment:12>
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 django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018e2f291788-acbe5c74-7b56-4bfe-8b3f-0b2a19e5a010-000000%40eu-central-1.amazonses.com.
