Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Wed, 24 Jul 2013 13:16:54 -0700
From: Ethan Furman <ethan@stoneleaf.us>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Python 3: dict & dict.keys()
References: <51EF2AD8.3080105@stoneleaf.us> <ksnrr9$k4t$1@ger.gmane.org> <ksp2it$21p$1@ger.gmane.org> <51F01D9E.2030903@stoneleaf.us> <kspbms$atn$1@ger.gmane.org>
In-Reply-To: <kspbms$atn$1@ger.gmane.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.5063.1374698328.3114.python-list@python.org>
Lines: 42
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:51165

On 07/24/2013 12:59 PM, Stefan Behnel wrote:
>
> I think the question is: how else would you implement an interface that
> doesn't restrict itself to returning a list? I mean, previously, the
> following was totally inefficient in terms of memory:
>
>      value in d.values()
>
> It now avoids creating an intermediate list copy of the values, thus
> running with no additional memory overhead (well, a constant, ok, but
> definitely not linear) and keeps users from resorting to the much more
> unfriendly
>
>      for v in d.itervalues():
>          if v == value:
>              return True
>      else:
>          return False
>
> in order to achieve the same thing. You can now even efficiently do this
> for items, i.e.
>
>      (key, value) in d.items()
>
> That's equivalent to "d[key] == value", but uses a different protocol,
> meaning that you don't have to make a copy of the dict items in order to
> pass it into something that works on a set or iterable of 2-tuples (which
> is a way more generic interface than requiring a dict as input). These
> things chain much more cleanly now, without first having to explain the
> difference between items() and iteritems() and when to use which.
>
> It's all about replacing the old copy-to-list interface by something that
> is efficiently processable step by step. All of this started back when
> iterators became a part of the language, then generators, and now dict
> views. They may not be the hugest feature ever, but they definitely fit
> into the language much better and much more cleanly than the old
> copy-to-list way.

Thank you. :)

--
~Ethan~