Naming conventions for iterator methods?

Francis Avila francisgavila at yahoo.com
Mon Dec 22 19:25:35 EST 2003


John J. Lee wrote in message <87fzfch0bu.fsf at pobox.com>...
>How do people name their iterator methods / functions?
>
>eg. .iter_foo(), .foo_iter(), .iterfoo(), .fooiter(), .foos(), ...?
>
>Of course, dicts have .iterkeys(), .itervalues() and .iteritems(), but
>I don't like having words run together like that.

Well, you have already discovered and rejected what little convention there
is. ;)

It seems that the emerging convention is .iter<noun>s() for methods, and
i<verb>() for functions (see itertools).  This is what I stick to, as well.

>The class pullparser.PullParser can iterate over HTML tokens (which
>includes tags, comments, declarations, etc.) or just over the tokens
>representing tags, skipping all other tokens.  So __iter__ returns an
>iterator over tokens, and tag_iter() over tags.  Then I wondered if I
>should be following a standard naming convention.  There's a method
>.get_tag(), so I guess the should be related to that in some obvious
>way.

I would have done .itertags().  This seems the most natural to me: iter +
plural of thing to be iterated.  I suppose it's just because it follows the
dict convention, but it fits my way of thinking naturally, too.

I don't like tag_iter(), because it seems more a noun than a verb.  I almost
expect it to *be* the iterator rather than *return* one.  Having a verb as a
function name is clearer.

All this said, it's more important to be consistent with yourself than with
the convention.  *That* said, you'll be loved more if your self-consistency
is also consistent with convention. :)
--
Francis Avila





More information about the Python-list mailing list