Opened 15 years ago

Closed 3 weeks ago

#9990 closed Bug (fixed)

Management shell autocomplete breaks PYTHONSTARTUP autocomplete

Reported by: bruno Owned by: nobody
Component: Core (Management commands) Version: dev
Severity: Normal Keywords: management shell command
Cc: Adam Zapletal Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

  • 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.

Attachments (3)

shell.diff (3.0 KB ) - added by bruno 15 years ago.
shell-1.3-svn-r15506.patch (3.2 KB ) - added by bruno desthuilliers <bruno.desthuilliers@…> 13 years ago.
patch against r15506
shell-r16501.patch (3.3 KB ) - added by bruno desthuilliers <bruno.desthuilliers@…> 13 years ago.
patch against r16501, cleaned up comments and better handlin of "use_plain"

Download all attachments as: .zip

Change History (13)

by bruno, 15 years ago

Attachment: shell.diff added

comment:1 by Jacob, 15 years ago

Triage Stage: UnreviewedDesign decision needed

comment:2 by Chris Beaven, 13 years ago

Severity: Normal
Type: Bug

comment:3 by bruno.desthuilliers@…, 13 years ago

Component: Core (Other)Core (Management commands)
Easy pickings: unset
UI/UX: unset

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.

by bruno desthuilliers <bruno.desthuilliers@…>, 13 years ago

Attachment: shell-1.3-svn-r15506.patch added

patch against r15506

comment:4 by Jannis Leidel, 13 years ago

Patch needs improvement: set
Triage Stage: Design decision neededAccepted

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

by bruno desthuilliers <bruno.desthuilliers@…>, 13 years ago

Attachment: shell-r16501.patch added

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

in reply to:  4 comment:5 by bruno desthuilliers <bruno.desthuilliers@…>, 13 years ago

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.

comment:6 by bruno.desthuilliers@…, 12 years ago

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 ?

comment:7 by Russell Keith-Magee, 12 years ago

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.

comment:8 by Adam Zapletal, 3 weeks ago

Cc: Adam Zapletal added
Patch needs improvement: unset

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.

comment:9 by Mariusz Felisiak, 3 weeks ago

Has patch: unset

in reply to:  8 comment:10 by Mariusz Felisiak, 3 weeks ago

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top