Type returned from .keys() is not checked

[bhandley]

BPO	1004669
Nosy	@rhettinger

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/rhettinger'
closed_at = <Date 2004-08-07.04:55:53.000>
created_at = <Date 2004-08-06.15:08:08.000>
labels = ['interpreter-core']
title = 'Type returned from .keys() is not checked'
updated_at = <Date 2004-08-07.04:55:53.000>
user = 'https://bugs.python.org/bhandley'

bugs.python.org fields:

activity = <Date 2004-08-07.04:55:53.000>
actor = 'rhettinger'
assignee = 'rhettinger'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2004-08-06.15:08:08.000>
creator = 'bhandley'
dependencies = []
files = []
hgrepos = []
issue_num = 1004669
keywords = []
message_count = 5.0
messages = ['21969', '21970', '21971', '21972', '21973']
nosy_count = 3.0
nosy_names = ['rhettinger', 'isandler', 'bhandley']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1004669'
versions = ['Python 2.4']

[bhandley]

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

[isandler]

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

[bhandley]

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?

[rhettinger]

Logged In: YES
user_id=80475

It's a bug. Will fix.

[rhettinger]

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.