Where is the `dict_keys` (and `dict_values` (and `dict_items`)) class?

[George-Ogden]

How can I check if an object is a dict_keys() in Python?

My current options are:

1. seems bad style:

dict_keys = type(dict().keys())
is_dict_keys = isinstance(foo, dict_keys)

2. overzealously matches:

from collections.abc import KeysView
is_dict_keys = isinstance(foo, KeysView)

There's no way to import this from the types library and there's no documentation about it in the Dictionary view objects section of the documentation.
Is there a better way to do this? Is dict_keys intentionally excluded from the documentation?

[George-Ogden]

I also notice:

## views ##
dict_keys = type({}.keys())
dict_values = type({}.values())
dict_items = type({}.items())

in the current collections.abc library

[JelleZijlstra]

As you noticed, the types are present in the collections.abc module as an implementation detail, but that shouldn't be relied upon. In user code, it's also possible to retrieve the types using the same technique collections.abc uses.

What's the use case for needing these types in user code? If there's a good justification, we could add them to the types module (e.g., as types.DictKeysType), but I am not sure what code needs to specifically handle the concrete dict_keys type and not other implementations of the KeysView ABC.

[terryjreedy]

I am included to close this as 'nothing more needed'. Either 1 or 2 look fine to me. There are about 20 of these implementation classes left out of types (and likely more not listed in .abc and I think they should continue to be omitted.

[picnixz]

I think those dict_keys, dict_values and dict_items are implementation details. As you observed, we provide ABC's and those should be sufficient. If you're worried about matching exact semantics in a compatible manner, option (1) would still be preferrable but I wouldn't add it to the types module as it's a detail.

Note that collections.abc has the following comment about those implementation details:

# Note:  in other implementations, these types might not be distinct
# and they may have their own implementation specific types that
# are not included on this list.

We list quite a lot in collections.abc already, especially some iterator-types of iterable builtins (e.g., type(iter([])) and type(iter(reversed([]))) which are different in CPython).

[George-Ogden]

I'm writing a pretty printer as part of a debugging library: https://github.com/George-Ogden/dbg
I want to override the display of dict_keys by checking the type of an appropriate class
I notice that pprint does the same thing

[George-Ogden]

I'm happy to close this as "nothing more needed" and use the abc for now.

[picnixz]

I will go ahead and close it as wont fix. If you're worried about the exact types, solution (1) is still correct and not that bad style.