#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

 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

 > 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 

Reply via email to