python-dev summary 2001-02-01 - 2001-02-15

[Marcin 'Qrczak' Kowalczyk]

Thu, 15 Feb 2001 16:56:54 +0000 (GMT), Michael Hudson <mwh21 at cam.ac.uk> pisze:

>  Discussion went round and round for a while and moved
>  on to more general iteration constructs, prompting Ka-Ping Yee to
>  write a PEP entitled "iterators":
> 
>   <http://python.sourceforge.net/peps/pep-0234.html>

What about mp_iterkeys trying to use __iteritems__ after __iterkeys__ is
not available, before failing back to __iter__? Similarly __itervalues__.
It would allow a mapping to implement only __iteritems__, obtaining correct
iteration over keys and values for free.

What about introducing a "black hole" or "wildcard pattern" for
assignments?
    e0, e1, _, _ = some_4_tuple
    for k:_ in mapping:
    for _:v in mapping:
If there is code using _ as a variable name, maybe some different name.
But it's _ in some other languages (ML, Haskell, Prolog, Clean).

After these two things increasing the complexity :-( let me propose
a simplification. Have _ as above, but don't have mp_iterkeys nor
mp_itervalues. The mapping iteration protocol uses only mp_iteritems
and __iteritems__ / __iter__. Iteration over keys or values is
expressed as iteration over items, while throwing half of each pair
into a black hole.

For mp_iteritems implemented in terms of __iter__ (i.e. sequences
treating as mappings from integers) and for builtin types the
interpreter can generate as efficient code for k:_ and _:v iteration
as if there were separate iterkey and itervalue protocols. For user
classes it's a bit worse (an unnecessary 2-tuple is created), but
the simplification of concepts certainly justifies it.

So finally I propose adding black holes, and having only the iteritems
protocol and syntax. iterkeys and itervalues are just instances of
these concepts put together, not separate concepts.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK