PyMapping_Check returns 1 for lists

@birkenfeld

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']

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

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.

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.

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?

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.

Guido, can we have your take on this?

Rather than introduce "fixes" that break code and hurt performance, I
think it would be better to deprecate PyMapping_Check() and wait for a
fast, clean C version of the ABCs (that is supposed to be our one
obvious way to do it).

Do you also advocate deprecating PySequence_Check()? Both are useful
APIs to know what you're dealing with.

As for the "clean C version of the ABCs", I'm afraid we could wait quite
a bit, since that's a lot more work and nobody seems really interested
in the matter.

FWIW, the spreadsheet example has been around for years and I know of
more than one private company that has made heavy use of code modeled
on that example (not for spreadsheets, but as a hook for eval). So, I
don't think the new "keys" check should be backported.

Well, I'm not proposing to backport it, but to fix things in 3.2.

Do you also advocate deprecating PySequence_Check()?

Perhaps just document PyMapping_Check() as being less informative than before (now it has false positives for sequences).

As for the "clean C version of the ABCs",
I'm afraid we could wait quite a bit

That may be true. I hope not. The ABCs were meant to solve exactly this problem. At this point, I would rather ignore the problem for 3.2 than to implement a less clean alternative.

> As for the "clean C version of the ABCs",
> I'm afraid we could wait quite a bit

That may be true. I hope not. The ABCs were meant to solve exactly
this problem. At this point, I would rather ignore the problem for
3.2 than to implement a less clean alternative.

Also, please note that checking for ABCs would not solve the
test_builtin failure, since the class there doesn't implement the
Mapping ABC (and doesn't claim to either).

We've hit this problem today.

What are we supposed to do in the meantime?

Not use PyMapping_Check?

On Mon, Feb 2, 2015, at 14:02, Buck Golemon wrote:

Buck Golemon added the comment:

We've hit this problem today.

What are we supposed to do in the meantime?

----------
nosy: +bukzor

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue5945\>

Proposed wording doesn't looks much informative to me. Maybe just say that PyMapping_Check() also returns 1 for sequences that support slicing? And recommend PyMapping_Check() && !PySequence_Check() for true mapping test?

I propose an alternate PR 7029 which also adds other improvements to the documentation of mappings and sequences C API.

New changeset f5b1183 by Serhiy Storchaka in branch 'master':
bpo-5945: Improve mappings and sequences C API docs. (GH-7029)
f5b1183

New changeset e1a78ca by Miss Islington (bot) in branch '3.7':
bpo-5945: Improve mappings and sequences C API docs. (GH-7029)
e1a78ca

New changeset 93e9fb5 by Serhiy Storchaka in branch '3.6':
[3.6] bpo-5945: Improve mappings and sequences C API docs. (GH-7029). (GH-7049)
93e9fb5

Are these changes enough? Can this issue be closed now?

Navigation Menu

Repository navigation

PyMapping_Check returns 1 for lists #50195

10 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

PyMapping_Check returns 1 for lists #50195

Description

Activity

jmillikin commented on May 5, 2009

pitrou commented on May 14, 2009

benjaminp commented on May 14, 2009

rhettinger commented on May 14, 2009

pitrou commented on May 14, 2009

pitrou commented on Jan 4, 2011

10 remaining items

pitrou commented on Jan 6, 2011

rhettinger commented on Jan 6, 2011

pitrou commented on Jan 6, 2011

bukzor commented on Feb 2, 2015

benjaminp commented on Feb 2, 2015

serhiy-storchaka commented on Mar 6, 2017

serhiy-storchaka commented on May 21, 2018

serhiy-storchaka commented on May 22, 2018

miss-islington commented on May 22, 2018

serhiy-storchaka commented on May 22, 2018

serhiy-storchaka commented on Jun 3, 2018

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions