Opened 7 years ago

Last modified 3 years ago

#9990 new Bug

Management shell autocomplete breaks PYTHONSTARTUP autocomplete

Reported by: bruno Owned by: nobody
Component: Core (Management commands) Version: master
Severity: Normal Keywords: management shell command
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
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 7 years ago.
shell-1.3-svn-r15506.patch (3.2 KB) - added by bruno desthuilliers <bruno.desthuilliers@…> 4 years ago.
patch against r15506
shell-r16501.patch (3.3 KB) - added by bruno desthuilliers <bruno.desthuilliers@…> 4 years ago.
patch against r16501, cleaned up comments and better handlin of "use_plain"

Download all attachments as: .zip

Change History (10)

Changed 7 years ago by bruno

comment:1 Changed 6 years ago by jacob

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

comment:2 Changed 4 years ago by SmileyChris

  • Severity set to Normal
  • Type set to Bug

comment:3 Changed 4 years ago by bruno.desthuilliers@…

  • Component changed from Core (Other) to 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.

Changed 4 years ago by bruno desthuilliers <bruno.desthuilliers@…>

patch against r15506

comment:4 follow-up: Changed 4 years ago by jezdez

  • Patch needs improvement set
  • Triage Stage changed from Design decision needed to Accepted

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

Changed 4 years ago by bruno desthuilliers <bruno.desthuilliers@…>

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

comment:5 in reply to: ↑ 4 Changed 4 years ago by 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.

comment:6 Changed 3 years ago by 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 ?

comment:7 Changed 3 years ago by russellm

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.

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