On Wed, Sep 2, 2020 at 1:54 AM tyson andre <tysonandre...@hotmail.com> wrote:
> Hi Lynn and Nikita, > > > To be in line with naming conventions, I would suggest calling these > > iter_any() and iter_all(), using iter_* as the prefix for our future > > additions to the "functions that work on arbitrary iterables" space. > > iterable_any() and iterable_all() would work as well, though are > > unnecessarily verbose. > > I'd also feel like iter_any() could get confused with iterator_apply() for > Traversable > in terms of whether it's shorthand for iterator or iterable when learning > the language. > > There's been more discussion than I expected on this, arguments for both > options, and I'm not sure what the overall sentiment of voters is. > I was considering creating a straw poll on the wiki with 2 questions to > guide the final version of the RFC/PR: > > 1. Name choice (iterator_all(), iter_all(), or all(), or no interest in > adding the functionality) > 2. Interest in future RFCs to extend support to keys and entries > > Thanks, > - Tyson The main thing I'm concerned about is that once we start extending this area (I assume that any & all are not going to be the last additions in this space) we will quickly run into function names that are either too generic or outright collide. For example, what if we want to add an iterator-based version of range()? Do we *really* want to be forced to pull a Python and call it xrange()? That's about as good as real_range()... As such, I think it's important to prefix these *somehow*, though I don't care strongly how. Could be iter_all() or iterable_all(). We might even make it iterator_all() if we also adjust other existing iterator_* functions to accept iterables. I'd also be happy with iter\all() or iterable\all(), but that gets us back into namespacing discussions :) Regards, Nikita
