Opened 11 years ago
Closed 11 years ago
#23675 closed Cleanup/optimization (wontfix)
Default value for optional parameter "default" in the model field reference is not specified
| Reported by: | Paul Dejean | Owned by: | nobody |
|---|---|---|---|
| Component: | Documentation | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | yes | UI/UX: | no |
Description
https://docs.djangoproject.com/en/dev/ref/models/fields/#default
Optional paramaters in python always have a default value. This default value should be documented.
In this case the default value for the optional parameter "default" is not documented.
Change History (2)
comment:1 by , 11 years ago
| Easy pickings: | set |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
| Type: | Bug → Cleanup/optimization |
comment:2 by , 11 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
I beg to differ.
There are three strategies for defining functions with optional keyword arguments:
arg=None: this works well whenNonedoesn't make sense as an argument. The target function can assume that the argument wasn't passed if it'sNone.arg=GUARDwhereGUARDis a private singleton: this variant is required when the target function needs to be able to tell apart "arg set toNone" and "arg not passed", which is the case here.**kwargs: this is an alternative to 2. The target function can check if'arg' in kwargsto check if arg was passed.
Here, Django uses a different code path when the default argument is provided and when it isn't provided. As a consequence, Django doesn't use its value when it isn't provided. The argument doesn't have a default value; it simply isn't used at all. Implying there's a default value would be misleading and confuse users.
It happens that this particular piece of code is implemented with pattern 2 instead of 3, which makes it look like there's a default value, but that isn't something the users should be aware of. Worse, documenting NOT_PROVIDED would ruin pattern 2, because it only works as long as users don't know the guard value!
If you aren't convinced yet, I'll simply say that this bug report is based upon the idea that "optional paramaters in python always have a default value", which is wrong. Any function that takes **kwargs has optional parameters without a default value -- see django.shortcuts.render for a good example.
Hi,
I think the reason why it's not currently documented is that the default is the special value
django.db.models.NOT_PROVIDEDwhich is not documented either.I don't believe there's any reason why this special value should remain undocumented so I'd say let's do it!
Thanks.