Naming conventions for iterator methods?
John J Lee
jjl at pobox.com
Tue Dec 23 14:14:19 CET 2003
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
> 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.
More information about the Python-list