Changes between Initial Version and Version 1 of Ticket #19737
- Timestamp:
- Feb 4, 2013, 11:55:14 AM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #19737 – Description
initial v1 1 The only benefit of the "shell" management command is that it saves you from having to set the DJANGO_SETTINGS_MODULE env var, and instead automatically use the one set in ` `manage.py``. This is a pretty minor benefit; it's not hard to use your favorite technique (alias, script, whatever) to reduce the number of characters you need to type to run ``DJANGO_SETTINGS_MODULE=someproj.settings python``, with the added advantage that you can easily use any python REPL you like without having to patch "shell" to explicitly support it.1 The only benefit of the "shell" management command is that it saves you from having to set the DJANGO_SETTINGS_MODULE env var, and instead automatically use the one set in `manage.py`. This is a pretty minor benefit; it's not hard to use your favorite technique (alias, script, whatever) to reduce the number of characters you need to type to run `DJANGO_SETTINGS_MODULE=someproj.settings python`, with the added advantage that you can easily use any python REPL you like without having to patch "shell" to explicitly support it. 2 2 3 3 The downside of having "shell" in Django is that it's a non-trivial maintenance burden to decide which REPLs to support, add support for them, and then update/fix that support through the years. We've already seen a steady stream of tickets related to various edge-cases in IPython startup, not to mention the major API changes in recent IPython versions. There's no reason for Django to have to be maintaining code related to IPython.