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