Document that PositiveIntegerField and co have a misleading name

[Gergely Kontra <pihentagy+djangoproject@…>]

I find the PositiveIntegerField (and similar firends) name misleading. It allows zero.

Using UnsignedIntegerField or something like that cat solve that confusion.

[Adam Vandenberg]

Remembering my distant math major past, I suppose "NonNegativeInteger" would be more technically correct, but I'm rather OK with PositiveInteger including zero, it's what I expected.

[Jeff Anderson]

Calling it something else would be the "right" way to fix this. I'm +1 for calling it UnsignedInteger, because that is really what it is. This will preserve the current behaviour, and to make PositiveInteger act properly, we could simply add code to it to reject 0 when validating.

Writing a patch like this should be fairly trivial.

[jcrocholl]

Very simple patch to add UnsignedIntegerField and UnsignedSmallIntegerField as subclasses of PositiveIntegerField and PositiveSmallIntegerField.

[(none)]

Milestone post-1.0 deleted

[Karen Tracey]

#10719 marked as a dup. I favor its recommendation to explicitly note in the docs these fields include zero as valid input. I don't think we need yet more names for the same thing and it would be backwards-incompatible at this point to start disallowing zero for these fields.

[jonlesser@…]

I was surprised to get a ZeroDivisionError error when using this field with a ModelForm, because as people have already pointed out, 0 is not a positive integer. So how could that be valid input for the PositiveIntegerField?

Now I'm just specifying a different form field in my ModelForm: forms.IntegerField(min_value=1).

IMO changing the min_value form field default for this field from 0 to 1 is better than making a new UnsignedIntegerField class. At the very least, a caution note in the docs for PositiveIntegerField.

[Alex Gaynor]

Speaking with Jacob: we can't change this due to backwards compatibility, however the docs should clearly note this.

[Paul Collins]

Replying to Alex:

Speaking with Jacob: we can't change this due to backwards compatibility, however the docs should clearly note this.

So it's a trivial patch to the docs, but I guess it makes the required point.

[Bas Peschier]

Might it be a good thing to actually mention we know positive should mean "higher than 0", but the field accepts 0 due to backwards compatibility? It saves people a search on the trac for tickets relating to it.

[Julien Phalip]

Yes, I agree with bpeschier. Could you please update the patch?

[Paul Collins]

Should I include that kind of information as a ..note:: or just put something to the effect of

Like an :class:IntegerField, but must be positive. Also accepts 0 for backward compatibility reasons (link to this ticket)?

[Julien Phalip]

Replying to paulcollins:

Should I include that kind of information as a ..note:: or just put something to the effect of

Like an :class:IntegerField, but must be positive. Also accepts 0 for backward compatibility reasons (link to this ticket)?

No need to use a "..note" directive. Just need to say that, despite its name, it accepts 0 for B-C reasons.

[Paul Collins]

Update per comment 15

[Paul Collins]

Same idea without the link to this ticket

[Paul Collins]

Replying to julien:

Replying to paulcollins:

No need to use a "..note" directive. Just need to say that, despite its name, it accepts 0 for B-C reasons.

Two versions one with the link to this ticket and one without. Let me know if you need some other change to it, otherwise feel free to use either one :)

[Julien Phalip]

Great, thanks ;)

[Julien Phalip]

In [16972]:

Fixed #7609 -- Noted in the model fields reference documentation that PositiveIntegerField accepts the value 0 for backwards-compatibility reasons. Thanks to everyone involved in the resolution of this issue, including Paul Collins for the patch.

[anonymous]

+1 for UnsignedIntegerField