Changes between Version 1 and Version 2 of Ticket #29301, comment 8
- Timestamp:
- May 21, 2018, 11:42:03 AM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #29301, comment 8
v1 v2 5 5 (B) If we take the interpretation that management commands are ultimately in control of their arguments, I would expect Django to back off if sees that a management command added its own argument with a conflicting name. Adding new default arguments would then be a minor change. 6 6 7 Before the original patch for this ticket was merged, add_arguments() was allowed even more leeway than (B), potentially removing default arguments outright, setting a custom formatter, or doing other unusual things, even though those possibilities were not documented. I don't think we should necessary support arbitrary actions in add_arguments().7 (C) Before the original patch for this ticket was merged, add_arguments() was allowed even more leeway than (B), potentially removing default arguments outright, setting a custom formatter, or doing other unusual things, even though those possibilities were not documented. I don't think we should necessary support arbitrary actions in add_arguments(). 8 8 9 I'm personally + 0on approach (B). It would involve a small additional patch where Django checks whether each default argument already existed before adding its own.9 I'm personally +1 on approach (B). It would involve a small additional patch where Django checks whether each default argument already existed before adding its own. 10 10 11 11 ---