Changes between Initial Version and Version 1 of Ticket #19737


Ignore:
Timestamp:
Feb 4, 2013, 11:55:14 AM (12 years ago)
Author:
Carl Meyer
Comment:

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.
     1The 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.
    22
    33The 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.
Back to Top