[].keys() and [].items() (Was: Why I think range is a wart)

[Huaiyu Zhu]

On Wed, 13 Mar 2002 22:39:02 GMT, Terry Reedy <tejarex at yahoo.com> wrote:
>>
>> [Clark C . Evans]
>> | Very nice idea.  This is PEP worthy.  It is nice beacuse it
>> | does not introduce anything new; a list can easily be viewed
>> | as a mapping having a positive integer domain.  This is simple,
>> | consistent, and quite elegant.
>>
>> I would like to see:
>>     .keys()
>>     .items()
>>     .iterkeys()
>>     .iteritems()
>
>I like this idea too.  Best suggestion so far for replacing
>range(len(skjf))./

Question:  Which is better:  items(x) or x.items()?

I think items(x) can just piggy-back on the current iterator protocol, and
can be made to work on any iteratable objects.

On the other hand, x.items() has to be implemented by each and every
list-like classes.  Their subclasses need to override them whenever
necessary. 

So else being equal, I'd prefer items(x) to x.items().


Question:  Which is better name: keys or indices?  items or indexed?  

I think the latter two (indices, indexed) are more descriptive of sequence
types.  This is especially true if one ever want to use a seqdict type.


Question: Which name is better: iterkeys or xkeys?

I thought the general trend is that x- prefix is going to be used for
iterators.  Then I found out that xrange(3) is not an iterator by itself.
And {} has iteritems, iterkeys, itervalues, instead of the x- variety.

So, suppose we'll have an xzip eventually, will it be called iterzip?


Huaiyu