PyMapping_Check returns 1 for lists

[jmillikin]

BPO	5945
Nosy	@birkenfeld, @rhettinger, @pitrou, @benjaminp, @jmillikin, @bukzor, @serhiy-storchaka, @ilevkivskyi, @miss-islington
PRs	bpo-5945: mapping.rst: PyMapping_Check(list) returns 1 #144 bpo-5945: Improve mappings and sequences C API docs. #7029 [3.7] bpo-5945: Improve mappings and sequences C API docs. (GH-7029) #7045 [3.6] bpo-5945: Improve mappings and sequences C API docs. (GH-7029). #7049

^{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 = None
closed_at = <Date 2018-06-04.10:38:51.810>
created_at = <Date 2009-05-05.21:47:15.152>
labels = ['interpreter-core', '3.8', 'type-bug', '3.7', 'docs']
title = 'PyMapping_Check returns 1 for lists'
updated_at = <Date 2018-06-04.10:38:51.809>
user = 'https://github.com/jmillikin'

bugs.python.org fields:

activity = <Date 2018-06-04.10:38:51.809>
actor = 'levkivskyi'
assignee = 'none'
closed = True
closed_date = <Date 2018-06-04.10:38:51.810>
closer = 'levkivskyi'
components = ['Documentation', 'Interpreter Core']
creation = <Date 2009-05-05.21:47:15.152>
creator = 'jmillikin'
dependencies = []
files = []
hgrepos = []
issue_num = 5945
keywords = ['patch']
message_count = 27.0
messages = ['87291', '87751', '87752', '87757', '87758', '125279', '125288', '125289', '125299', '125335', '125336', '125348', '125351', '125355', '125517', '125518', '125520', '125522', '125529', '235282', '235283', '289070', '317229', '317263', '317264', '317270', '318527']
nosy_count = 9.0
nosy_names = ['georg.brandl', 'rhettinger', 'pitrou', 'benjamin.peterson', 'jmillikin', 'bukzor', 'serhiy.storchaka', 'levkivskyi', 'miss-islington']
pr_nums = ['144', '7029', '7045', '7049']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue5945'
versions = ['Python 3.6', 'Python 3.7', 'Python 3.8']

[jmillikin]

In Python 2, PyMapping_Check will return 0 for list objects. In Python
3, it returns 1. Obviously, this makes it rather difficult to
differentiate between mappings and other sized iterables. In addition,
it differs from the behavior of the collections.Mapping ABC --
isinstance([], collections.Mapping) returns False.

Since most of the PyMapping_* functions don't seem to work properly on
lists, I believe this behavior is erroneous.

The behavior can be seen from a C extension, or if you're lazy, using
ctypes:

Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.CDLL('libpython2.6.so').PyMapping_Check(ctypes.py_object([]))
0

Python 3.0.1+ (r301:69556, Apr 15 2009, 15:59:22)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.CDLL('libpython3.0.so').PyMapping_Check(ctypes.py_object([]))
1

[pitrou]

I understand this is indeed unintuitive. The reason list objects support
the C "mapping protocol" in 3.x is that it is how slicing of lists (and
tuples, for that matter) is implemented. Perhaps the documentation
should carry a warning about this.

Unfortunately, right now there is no easy way in C to check that an
object implements a given ABC.

[benjaminp]

Personally, I think PyMapping_Check and PySequence_Check should be
deprecated and removed. Like their Python counterparts,
operator.isMappingType() and operation.isSequenceType(), they are
unreliable at best in the face of not LBYL and abcs.

[rhettinger]

Why did the list implementation get changed in Py3.x? Is it now
necessary for any subscripting type to put the same method in both the
sequence methods and mapping methods? Was this change necessary?

[pitrou]

Why did the list implementation get changed in Py3.x? Is it now
necessary for any subscripting type to put the same method in both the
sequence methods and mapping methods? Was this change necessary?

I think it's a case of foolish consistency. In py3k there are no opcodes
dedicated to slicing anymore, instead the slice object is passed to the
mapping's getitem method.

[pitrou]

Guido, can we have your take on this?