Naming conventions for iterator methods?

[John J Lee]

On Mon, 22 Dec 2003, [iso-8859-1] François Pinard wrote:

> [John J. Lee]
> > How do people name their iterator methods / functions?
>
> > eg. .iter_foo(), .foo_iter(), .iterfoo(), .fooiter(), .foos(), ...?
>
> I took the habit of naming such methods and functions with names
> starting with `all_', so I can write:
>
>     for name in all_names():
>        do something

I don't like that, because often my iterator-returning methods take
arguments to restrict the iterees: shop.iter_cheeses(variety="smelly").

> or maybe:
>
>     tokens = all_tokens()
>     ...
>     token = tokens.next()
>     ...

I just realised some of these methods of mine don't actually return
iterators, but merely objects supporting the iterator protocol.  In other
words, the returned objects have an .__iter__() method, but not a .next()
method (usually because I've quickly implemented the method by returning a
sequence, leaving the way open for a later reimplementation that, eg.,
returns a lazy iterator).  Would that surprise people from a method named
.iter_foo()?


> I find this more legible than forcing the string `iter' here and there,
> and leaves a bit more freedom to change the code later -- let's say, if
> I ever want to substitute a solid list for the iterator.  I can keep the
> `all_' prefix, while I would feel uncomfortable it were some `iter' in
> the names.  Granted, if I want to use `.next()', I'll have to plunk one
> more `iter()' in the code.

That's one data point :-)

I think I'll go with .foos(), for the same reason you choose .all_foos()
-- it'll make people read the docs if they need to know whether it's a
sequence, iterator, or object supporting the iterator protocol.


John