opposite of dict.items()

[Peter Otten]

Chad Netzer wrote:

>> If I could use the above in Py2.4, it would be even nicer, namely:
>> 
>> - convert itertools to builtins
> 
> The push is to have LESS builtins.  You can always import them in to the
> current namespace:
> 
> from itertools import izip

More than 20% (counted manually, so maybe wrong) of the builtins have been
added in the 2.x versions. So the question is rather what than if to
include. I use zip() more often than property(). I happen to see *both* as
core language features (can't remember having zipped anything in C or
Basic). But I could live with 

# do not mistake that as a proposal
from classfeatures import property, staticmethod 

>> - add irange(), perhaps as an alias for xrange() like file/open
> 
> BTW.  In the example you used, you COULD use xrange().  The only problem
> is that range has been extended, in 2.3, to accept longs, and xrange()
> only works with ints, and Guido wants it that way (he doesn't want to
> extend xrange()'s features, since it is a pain.)  irange(), if it ever
> appears, would presumably be fully range() compatible.

I did not want irange() as an *addition* but as an *alias* for xrange().
For new users, it would be easier to have a common prefix for all lazy
sequence operations.
In my example I took two steps at once (using xrange() instead of range()
and introducing the alias), which confused the issue. 
Think of the "perhaps" as bloat and remove it :-)
(As to the implementation details of xrange(), these have completely escaped
me until now)

> I suggested an irange to Raymond, and even coded one up, a while ago.
> He sees it as bloat, and rightfully so, since there is a push to allow
> optimizations of range that would achieve the same effect.  (ie. rather
> than remembering when to use range(), xrange(), or irange(), we could
> just always use range() and the language would do lazy evaluation
> whenever possible.)  Unless that avenue turns out to be a complete dead
> end, don't expect an irange().

Now *that* sounds interesting, but if it is feasible I would expect other
functions like ifilter() and imap() to be unified with their (at least for
the moment) builtin analogs.

Peter