Python variables obscur ipdb commands

This PR: #https://github.com/ipython/ipython/pull/9449 introduced annoying problem: I couldn’t step through the following code (execute line 3):

n = 1
next = 1
print('end')

Because n/next commands weren’t working:

$ ipdb test.py
> /tmp/test.py(1)<module>()
----> 1 n = 1
      2 next = 1
      3 print('end')

ipdb> next
> /tmp/test.py(2)<module>()
      1 n = 1
----> 2 next = 1
      3 print('end')

ipdb> next
> /tmp/test.py(3)<module>()
      1 n = 1
      2 next = 1
----> 3 print('end')

ipdb> next
1
ipdb> n
1
ipdb> !n
1
ipdb> !next
1

I discovered that in this case I can use standard pdb or I can get it to work in ipdb by using !!n (it still has a bug that @tcztzy tried to solve in https://github.com/ipython/ipython/pull/10035) but what do you think about changing this behavior: all ipdb builtin commands should work as they meant to and if we want to see python variables we use i.e.: !n instead of n. Variables’ names that are not ipdb commands could still be displayed by just writing their name.

StackOverflow thread

[takluyver]

#10050 reverts it. As the voting is currently 11-1 for reverting, I haven’t made it configurable at present - every config option adds complexity and potential bugs, so I’m reluctant to add them without a certain level of support.

We could also look at providing options to plug in externally developed debuggers - I don’t think our debugger is particularly great, and there are projects like pudb out there which have spent much more time than us on debugger UI.

[fperez]

Late to the party, but I wanted to say that I strongly support the reversion. Over and over we’ve encountered that customizations that try to be overly smart, even though well-intentioned, typically cause more confusion than they are worth. Over the years we’ve backed off on a number of those (made them optional when it’s easy to do in a simple way), and I think this falls in that category.

Thanks!