When passing a mapping object as the locals to eval, it
doesn't check that the return value of .keys() is a
tuple early enough, resulting in a SystemError:

>>> class C:
...     def __getitem__(self, item):
...         raise KeyError, item
...     def keys(self):
...         return 'a'
...
>>> c=C()
>>> print eval('dir()', globals(), c)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 0, in ?
SystemError: Objects/listobject.c:2110: bad argument to
internal function

Logged In: YES 
user_id=971153

Why do you think the existing behaviour is wrong?

All Python type checking is done at run time
E.g.
>>> 12+"123"
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unsupported operand types for +: 'int' and 'str'

How is your example different?

I would suggest to close the bug

Logged In: YES 
user_id=765626

If it raised a TypeError rather than SystemError I would
think it fine. I didn't think that python code should be
able to cause correct C code to generate `bad argument to
internal function'. To me, that sounds like `some C function
called some other C function badly', rather than just a bad
type from python.

In fact I believe that that is exactly what is happening.
Here are the final two lines from the backtrace:
#0  PyList_Sort (v=0x4029bc20) at Objects/listobject.c:2110
#1  0x0807b659 in PyObject_Dir (arg=0x0) at
Objects/object.c:1705

PyList_Sort seems to assume that it will always be passed a
list, hence it calls PyErr_BadInternalCall() if it's not.
Assuming this is true, either PyObject_Dir or PyMapping_Keys
should do the type checking and raise TypeError if it's not
a list. Doesn't PyErr_BadInternalCall() mean that someone
violated the C API of an internal function, therefore the
bug is in C code rather than python?

Logged In: YES 
user_id=80475

It's a bug.  Will fix.

Logged In: YES 
user_id=80475

Fixed.
See:
    Objects/object.c 2.220
    Lib/ test/test_builtin.py 1.33 

Thanks for the clear bug report and diagnosis.