Management shell autocomplete breaks PYTHONSTARTUP autocomplete

[bruno]

• create a PYTHONSTARTUP file setting up autocompletion with readline
• run manage.py shell
• neither the PYTHONSTARTUP's autocomplete nor the shell command default's one work

(tested on ubuntu linux and gentoo linux with Python 2.5.x)

The problem seems to come from the fact that the shell command install autocompletion _before_ executing the PYTHONSTARTUP.

The attached patch reverse the order of operations, and check readline.get_completer before trying to install it's own completer. Worksforme, *but* requires that the PYTHONSTARTUP script pass globals() to the completer (else we'd be back to #5082). It also just ignore the use_plain flag except to tell wether to use IPython or the default shell(cf #5936). There's perhaps something better to do to get the whole thing right (perhaps passing a 'DJANGO_SHELL=1') option to execfile ???), but this is a design decision so I leave it to you guys.

[bruno.desthuilliers@…]

2 years later and we (my whole team) are still manually patching shell.py release after release :-/

Attached is a patch against r15506 (django 1.3) which still works against the trunk as of r16500.

[bruno desthuilliers <bruno.desthuilliers@…>]

patch against r15506

[Jannis Leidel]

Seems like a good idea in general, but the patch definitely needs a cleanup, what's with the '# XXX' and '# BD-WSB'?

[bruno desthuilliers <bruno.desthuilliers@…>]

patch against r16501, cleaned up comments and better handlin of "use_plain"

[bruno desthuilliers <bruno.desthuilliers@…>]

Replying to jezdez:

Seems like a good idea in general, but the patch definitely needs a cleanup, what's with the '# XXX' and '# BD-WSB'?

New patch with cleaned-up comments and better handling of the "use-plain" option.

[bruno.desthuilliers@…]

4 years (yes : four years) later and we (my whole team) are still manually patching shell.py release after release :-/

Should I express how I feel about this ?

[Russell Keith-Magee]

Feel free to express whatever sentiments you like. That won't get your ticket into trunk any faster.

What *will* make things progress faster?

Look at the meta data for this ticket. The patch is currently listed as "Needs improvement". That means it's not going to hit anyone's radar to be reviewed for trunk. If this ticket is so critical to the operation of your team, you might want to consider spending a moment to either (1) address the problems that mean it isn't ready for trunk, or (2) update the metadata so that the ticket isn't misleading.

And to counter the next argument -- just flicking the "needs improvement" switch doesn't mean a bunch of people will jump to review it. This is a community of volunteers. Your ticket is one of almost 2000 that are currently open. The fact that this ticket has been open for 4 years, and the only comments on this ticket are from yourself and core developers pretty much indicates that the set of people affected by this problem is pretty small. Just because you're affected by this bug 99% of the time, doesn't mean 99% of people are affected by this bug.

If this is a problem that is critical to you, you're going to need to convince someone to pay attention to it. This may mean you need to spend some time working on someone else's problem first. Scratch someone else's back, and they might scratch yours.

[Adam Zapletal]

I looked into this and tested for a while, and I don't think the issue exists any longer:

1. Loading locals from a PYTHONSTARTUP file works fine in a Django shell
2. Having a PYTHONSTARTUP file does not break autocomplete for the Django shell
3. It seems to be expected behavior that the the autocomplete function from a PYTHONSTARTUP file does not work in the Django shell since readline can have one completer function. The completer function in the Django shell is the one it set itself, which overwrites one set up by a PYTHONSTARTUP file. ​https://docs.python.org/3/library/readline.html#readline.set_completer

I believe this was fixed by a combination of 1f6b2e7a658594e6ae9507c5f98eb429d19c0c9d and 1bbb98d9a4b7d83e422b14ae2429cb368eff5a13. This comment on GitHub may help to explain the fix: ​https://github.com/django/django/pull/13911#issuecomment-862764723

I can do more investigation on this if needed.

[Mariusz Felisiak]

I believe this was fixed by a combination of 1f6b2e7a658594e6ae9507c5f98eb429d19c0c9d and 1bbb98d9a4b7d83e422b14ae2429cb368eff5a13. This comment on GitHub may help to explain the fix: ​https://github.com/django/django/pull/13911#issuecomment-862764723

Thanks Adam, agreed let's close it.