A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-April/022094.html below:

[Python-Dev] Re: PEP 279

[Python-Dev] Re: PEP 279Guido van Rossum guido@python.org
Mon, 01 Apr 2002 23:05:52 -0500
After some more thinking about the name, I have two contenders left:
enumerate() and indexer().

Let me explain why I reject the others:

> iterindexed()-- five syllables is a mouthfull

Indeed.

> index()      -- nice verb but could be confused the .index() method

Indeed.

> indexed()    -- widely liked however adjectives should be avoided

Indeed.

> count()      -- direct and explicit but often used in other contexts

In particular, there's a list method by this name.  While that's in a
different namespace, I think the core language should be careful not
to pile too many meanings on the same name.

> itercount()  -- direct, explicit and hated by more than one person

Did they explain why they hated it?  "Hate it" alone doesn't get much
credit in my book.

> iteritems()  -- already used by dictionaries for key:value pairs

Which is a downside to me.  The symmetry between (key:value) for
mappings and (index:value) for sequences seems appealing but quickly
becomes a problem, e.g. "for i in <list>" iterates over the values but
"for i in <dict>" iterates over the keys.

So now I'd like to choose between enumerate() and indexer().  Any
closing arguments?

--Guido van Rossum (home page: http://www.python.org/~guido/)



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4