-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
isinstance(ConfigDict(...), collections.abc.Mapping)
returns False
#47
Comments
Rather than inheritance which might accidentally change the runtime behavior, using |
Inheriting the built-in ABC class looks fairly benign (see https://github.com/python/cpython/blob/b8b4b713c5f8ec0958c7ef8d29d6711889bc94ab/Lib/_collections_abc.py#L804 and https://github.com/python/cpython/blob/b8b4b713c5f8ec0958c7ef8d29d6711889bc94ab/Lib/_collections_abc.py#L936 ), but I'd be happy enough just to have |
Please consider this PR that does exactly that: #50 |
Describe the bug
isinstance(config_dict_obj, collections.abc.Mapping)
returnsFalse
even though it is a "dictionary" typeThis is because class
ml_collections.config_dict.ConfigDict
does not inherit Python built-in abstract base classcollections.abc.Mapping
, despite being a "dictionary" type, producing unexpected behavior when using reflection or duck-typing withisinstance(x, collections.abc.Mapping)
. This is especially problematic for serializing and logging code where it is common to apply different formatting to different collection types.See PR #46 for proposed solution.
To Reproduce
The following code snippet reproduces and illustrates the bug
Expected behavior
isinstance(config_dict_obj, collections.abc.Mapping)
should returnTrue
Environment:
Additional context
Correctly inheriting
collections.abc.Mapping
would also improve Python static type analysis tooling (eg Ruff)The text was updated successfully, but these errors were encountered: