Christopher Barker writes:
> Interesting -- in other recent threads, Ive felt that those of us that
> thought "iterators and `next" were relatively advanced concepts that
> newbies didn't need to learn were dismissed ...
I for one don't *dismiss* that idea iterators and next are advanced,
but I wonder if there aren't halfway explanations for *many* of the
issues that come up that
> doesn't really require the full concept of iterators and iterables
I also believe that *some* of the halfway explanations are useful to
new Pythonistas, and don't (necesssarily) leave them with
misconceptions, such David's implementation of "first_one_like_this"
and Andrew's explanation of files as streams ("they know where they're
going to read next").
(Note: AFAICS the only definition of iterable you need until you've
introduced ABCs and/or protocols is "you can usefully put iterables,
and nothing that isn't iterable, in the 'in' clause of a 'for'
statement". This is much simpler than explaining reasonably
completely what an iterator is and why you might care. It's obvious
why you care about iterables, of course.)
> Interestingly, this seems to contradict API design-wise, what's been pushed
> on recent threads:
>
> * Rather than adding a keyword argument that changes behavior, we should
> add another function to itertools (or the like)
This is a matter of taste. I subscribe to it; I thought Guido did
too, but he says that in this case at least he likes the flag.
> and
>
> * rather than add functionality to a built-in (or ABC), we should add
> utility functions that can act on many related types
This is a principle some subscribe to, yes, but it doesn't apply in
the zip case, since zip already acts on an tuple of arbitrary iterables.
It does apply to ABCs, but it's most persuasive when a highly abstract
ABC already has all the prerequisites for the function to work. For
example, iter() has an obvious implementation for any sequence, it's
basically just
def iterseq(seq):
def wrapper():
for i in range(len(seq)):
yield seq[i]
return wrapper()
and it works because all sequences already have __len__ and
__getitem__. Then for *unordered* containers like sets and dicts, you
can add a protocol (__iter__).
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/PTPCXCJT6EBJ46HQMUD3AWK7GL4ZX5ZH/
Code of Conduct: http://python.org/psf/codeofconduct/
