class FakeContainer:
	def __getitem__(self, key)
		raise KeyError(key)
pdb.run("pass",{},FakeContainer())

Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    pdb.run("pass",{},FakeContainer())
  File "C:\Program Files\Python37\lib\pdb.py", line 1590, in run
    Pdb().run(statement, globals, locals)
  File "C:\Program Files\Python37\lib\bdb.py", line 585, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "<string>", line 1, in <module>
  File "C:\Program Files\Python37\lib\bdb.py", line 88, in trace_dispatch
    return self.dispatch_line(frame)
  File "C:\Program Files\Python37\lib\bdb.py", line 112, in dispatch_line
    self.user_line(frame)
  File "C:\Program Files\Python37\lib\pdb.py", line 261, in user_line
    self.interaction(frame, None)
  File "C:\Program Files\Python37\lib\pdb.py", line 351, in interaction
    self.print_stack_entry(self.stack[self.curindex])
  File "C:\Program Files\Python37\lib\pdb.py", line 1453, in print_stack_entry
    self.format_stack_entry(frame_lineno, prompt_prefix))
  File "C:\Program Files\Python37\lib\bdb.py", line 549, in format_stack_entry
    if '__args__' in frame.f_locals:
  File "<pyshell#3>", line 3, in __getitem__
    raise KeyError
KeyError: 0

Obviously, the debugger shouldn't crash in this case (running code outside of the debugger works as expected, producing a NameError on variable reads and a TypeError whenever a name is assigned).

There is no a crash. There is just an exception raised when you pass an inappropriate object as locals. This is an expected behavior, and I do not think that anything need to be changed.

I agree that this behavior is normal, unless there is a use case for passing a partially implemented mapping object to pdb.run. However I cannot think of such a use case.

The thing is, though, that the same error occurs if a larger code being debugged calls `exec` or `eval` with such a mapping (`pdb.run("eval('1+1',{},FakeContainer())" also crashes with the same error), and the test suite contains code that evals other code in an incomplete mapping (test_var_annot_custom_maps in test_grammar)

Hmm, the example works for me (Python 3.6.5):

>>> import pdb
>>> class FakeContainer:
...     def __getitem__(self, key):
...             raise KeyError(key)
...
>>> pdb.run("eval('1+1',{},FakeContainer())")
> <string>(1)<module>()
(Pdb) c
>>>

As for exec/eval accepting an incomplete mapping, that strikes me as a less than thorough checking on the part of exec/eval, perhaps for performance reasons(?)

You have to step into the eval for the error to be raised.

This looks to me like an error in the user code. What is the use case of passing an object that does not implement the mapping interface as locals to pdb.run()?

An attempt to clarify the issue in my own mind:

def foo():
    # import pdb; pdb.set_trace()
    exec('pass', {}, FakeContainer())

This function runs successfully. But if you uncomment the pdb line and then step thru in the pdb console, there is an Exception.

I *think* the underlying principle is that code that runs normally should also run under pdb, which this example violates. However, to adhere to the principle 100% could be a very steep technical cost.

Alternatively, I'd argue that the function should NOT run even without pdb, since exec requires a (complete) mapping type according to the documentation. Perhaps the thing to do is to add more stringent type checking to exec and eval?

You cannot expect that running code under debugger does not have any effect. Otherwise there would not be any meaning in debugger. Running code under debugger has some side effects, and setting locals __return__ and __exception__ is one of them. If it exposes bugs in user code -- well, it is a purpose of debugger.

I think that there are two options for this issue.

1. Add a type check for locals in the frame constructor (and maybe at higher levels).

2. Close it as "not a bug". Using functions outside of documented scope has undefined behavior. Python usually does not check types of arguments. If it works -- it works, if not -- blame on you.

I think we should close this. It's not a problem you will come across if you're not looking for trouble, so there's no point trying to make the error message a little nicer.