Joshua Bronson added the comment:
Thank you for confirming that ChainMap.__iter__() would be in the same boat as
bidict if a similar .mapping attribute were ever added to dict_keyiterators.
The specifics of this issue are interesting, but even more interesting to me is
whatever learnings we
Raymond Hettinger added the comment:
To the list of four options I suggested for bidict, you can add one more.
Create a feature request for a C implementation of collections.abc.KeyView.
ISTM that your core issue is that bidict won't use the intended and guaranteed
solution because the
Joshua Bronson added the comment:
Dear Raymond,
Thanks so much for the detailed response!
I wonder if you could explain how this case is different from the following:
>>> c = collections.ChainMap({1: 1}, {1: 2})
>>> iter(c)
>>> isinstance(c, dict) # it's fine, we <3 duck typing!
False
Raymond Hettinger added the comment:
Hmm, I'm looking through the bidict code a bit more. Rather than saying the
dict views are being used in an unsupported way, it is more accurate to say
that your intended meaning for the *mapping* attribute differs from the
published meaning.
Note, the
Raymond Hettinger added the comment:
Sorry, but this isn't bug in Python. The documented and supported API is the
MappingView ABC where the _mapping attribute is private.
As an optimization, the bidict project has elected to forgo the supported API
and instead use a concrete implementation
New submission from Joshua Bronson :
As of bpo-40890 (released in Python 3.10), dict views now provide a public
.mapping attribute, intended to allow users to recover a mappingproxy pointing
to the original mapping.
However, this new attribute can actually point to the wrong mapping for some
