Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #3874 > unrolled thread

Re: suggestions, comments on an "is_subdict" test

Started byChris Rebert <clp2@rebertia.com>
First post2011-04-22 07:38 -0700
Last post2011-04-22 23:52 +0000
Articles 2 — 2 participants

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: suggestions, comments on an "is_subdict" test Chris Rebert <clp2@rebertia.com> - 2011-04-22 07:38 -0700
    Re: suggestions, comments on an "is_subdict" test Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-22 23:52 +0000

#3874 — Re: suggestions, comments on an "is_subdict" test

FromChris Rebert <clp2@rebertia.com>
Date2011-04-22 07:38 -0700
SubjectRe: suggestions, comments on an "is_subdict" test
Message-ID<mailman.750.1303483120.9059.python-list@python.org>
On Fri, Apr 22, 2011 at 6:55 AM, Vlastimil Brom
<vlastimil.brom@gmail.com> wrote:
> Hi all,
> I'd like to ask for comments or advice on a simple code for testing a
> "subdict", i.e. check whether all items of a given dictionary are
> present in a reference dictionary.
> Sofar I have:
>
> def is_subdict(test_dct, base_dct):
>    """Test whether all the items of test_dct are present in base_dct."""
>    unique_obj = object()
>    for key, value in test_dct.items():
>        if not base_dct.get(key, unique_obj) == value:
>            return False
>    return True
>
> I'd like to ask for possibly more idiomatic solutions, or more obvious
> ways to do this. Did I maybe missed some builtin possibility?
> I am unsure whether the check  against an unique object() or the
> negated comparison are usual.?

I second MRAB's all() suggestion. The use of object() as a higher-rank
None is entirely normal; don't worry about it.

Also, the following occurs to me as another idiomatic, perhaps more
/conceptually/ elegant possibility, but it's /practically/ speaking
quite inefficient (unless perhaps some dict view tricks can be
exploited):

def is_subdict(sub, larger):
    return set(sub.items()).issubset(set(larger.items()))

Cheers,
Chris

[toc] | [next] | [standalone]


#3895

FromSteven D'Aprano <steve+comp.lang.python@pearwood.info>
Date2011-04-22 23:52 +0000
Message-ID<4db214b9$0$29978$c3e8da3$5496439d@news.astraweb.com>
In reply to#3874
On Fri, 22 Apr 2011 07:38:38 -0700, Chris Rebert wrote:

> Also, the following occurs to me as another idiomatic, perhaps more
> /conceptually/ elegant possibility, but it's /practically/ speaking
> quite inefficient (unless perhaps some dict view tricks can be
> exploited):
> 
> def is_subdict(sub, larger):
>     return set(sub.items()).issubset(set(larger.items()))

That cannot work if either dict contains an unhashable value:

>>> d = {2: []}
>>> set(d.items())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'


But if you know your dict items are hashable, and your dicts not 
especially large, I don't see why we should fear the inefficiency of 
turning them into sets. Worrying about small efficiencies is usually 
counter-productive, especially in a language like Python that so often 
trades off machine efficiency for developer efficiency.


-- 
Steven

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web