Skip to content

Improve implementation of get() in MultiSelectDict #292

Description

@pvandyken

I was confronted with a current limitation of our MultiSelectDicts: it is currently somewhat difficult to select only the keys that are contained inside the dict. You need something like this:

inputs['FA'].wildcards[
    tuple({"subject", "session"} & inputs["FA"].wildcards.keys())
])

If one of the items in the tuple is not found in the dict, you (sensibly) get a KeyError. So we prefilter our keys by the keys found in the dict to avoid the error.

In normal dicts, you have .get() to retrieve keys which may or may not be present. Its optional behaviour does not extend to tuples, however. In fact, MultiSelectDict.get() does not work with tuples at all!

I would propose the following behaviour:

If a string (the only valid key type currently) is passed to .get(), the behaviour is exactly the same as currently.

If a tuple is passed, then the method works with the same semantics as a defaultdict. Instead of default as the secondary argument, we have (the implicitly named) default_factory. As in defaultdict, it may be given either a 0-arg callable or None.

  • If None, then only the keys found in the parent dict will be returned in the child dict. If none of the keys are found, you get an empty dict.
  • If a callable, then keys not found in the parent dict will be lazily populated with the result of the callable.
  • Unlike a defaultdict:
    • Unlike a defaultdict, only keys originally passed to the get method will be valid. Other arbitrary keys will always give a key error.
    • The keys passed in the construction of the dict will be immediately deemed "present". In other words, querying key in child_dict will return True
  • The logic above applies to nested .get calls. If a key is "added" to a MultiSelectDict via a .get call, it will be deemed present in subsequent calls to .get

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions