[Python-Dev] Re: Sets: elt in dict, lst.include

[Ka-Ping Yee]

On Sat, 3 Feb 2001, Tim Peters wrote:
> They're simply distinct issues to me.  Whether people want special syntax
> for iterating over dicts is (to me) independent of how the iteration
> protocol works.  Dislike of the former should probably be stabbed into
> Ping's heart <wink>.

Ow!  Hey.  :)

We have shorthand like x[k] for spelling x.__getitem__[k];
why not shorthand like 'for k:v in x: ...' for spelling
'iter = x.__iteritems__(); while 1: k, v = iter() ...'?

Hmm.  What is the issue really with?

    - the key:value syntax suggested by Guido (i like it quite a lot)

    - the existence of special __iter*__ methods (seems natural to me;
      this is how we customize many operators on instances already)

    - the fact that 'for k:v' checks __iteritems__, __iter__, items,
      and __getitem__ (it *has* to check all of these things if it's
      going to play nice with existing mappings and sequences)

    - or something else?

I'm not actually that clear on what the general feeling is about
this PEP.  Moshe seems to be happy with the first part but not
the rest; Tim, do you have a similar position?  Eric and Greg both
disagreed with Moshe's counter-proposal; does that mean you like
the original, or that you would rather do something different
altogether?

Moshe Zadka wrote:
> dict.iteritems() could return not an iterator, but a magical object
> whose iterator is the requested iterator. Ditto itervalues(), iterkeys()

Seems like too much work to me.  I'd rather just have the object
produce a straight iterator.  (By 'iterator' i mean an ordinary
callable object, nothing too magical.)  If there are unusual
cases where you want to iterate over an object in several
different ways i suppose they can create pseudo-sequences in the
manner you described, but i think we want to make the most common
case (iterating over the object itself) very easy.  That is, just
implement __iter__ and have it produce a callable.

Marc A. Lemburg wrote:
> The idea is simple: put all the lookup, order and item building
> code into the iterator, have many of them, one for each flavour
> of values, keys, items and honeyloops, and then optimize the
> for-loop/iterator interaction to get the best performance out
> of them.
>
> There's really not much use in adding *one* special case to
> for-loops when there are a gazillion different needs to iterate
> over data structures, files, socket, ports, coffee cups, etc.

I couldn't tell which way you were trying to argue here.  Are you
in favour of the general flavour of PEP 234 or did you have in mind
something different?  Your first paragraph above seems to describe
what 234 does.



-- ?!ng

"There's no point in being grown up if you can't be childish sometimes."
    -- Dr. Who