On May 13, 2020, at 20:49, Christopher Barker <pythonchb@gmail.com> wrote:
On Wed, May 13, 2020 at 7:50 PM Andrew Barnert <
abarnert@yahoo.com> wrote:
But that’s the wrong generalization. Because sets also work the same way, and they aren’t Sequences. Nor are dict views, or many of the other kinds of things-that-can-be-iterated-over-and-over-independently.
But file.readline() does not return any of those objects. It returns a list. If you see this as an opportunity to teach about the iteration protocol, then sure, you'd want to make that distinction. But I think the file object is the wrong first example -- it's an oddball, having both the iteration protocol, AND methods for doing most of teh same things.
Agreed, it’s not an ideal first example, and zip or map would be much better. Unfortunately, files seem to be the example that many people run into first. (Or maybe lots of people do run into map first, but fewer of them get confused and need to go ask for help?) When you’re teaching a class, you can guide people to hit the things you want them to think about, but the intern, or C# guru who only touches Python once a year, or random person on StackOverflow that I’m dealing with apparently didn’t take your class. This is where they got confused, so this is what they ask about.
Most iterables don't have the equivalent of readlines() or readline() -- and in this case, I think THAT's the main sorce of confusion, rather than the iterable vs iterator distinction.
But notice that they’re already writing `for line in f:`. That means they *do* understand that files are iterables.
Sure, they probably don’t know the word “iterable”, but they understand that files are things you can use in a for loop (and that’s all “iterable” really means, unless you’re trying to implement rather than use them).
And honestly, if Python didn’t make iteration so central, I’m not sure as many novices would get that far that fast in the first place. Imagine if, instead of just calling open and then doing `for line in f:`, you had to call an opener factory to get a filesystem opener, call that to get a file object, bind a line-buffered read stream to it, then call a method on that read stream with a callback function that processes the line and makes the next async read call. Anyone who gets that far is probably already a lot more experienced with JavaScript than someone who iterates their first file is with Python.
> > You can explain it anyway. In fact, you _have_ to give an explanation with analogies and examples and so on, and that would be true even if there were a word for what lists are. But it would be easier to explain if there were such a word, and if you could link that word to something in the glossary, and a chapter in the tutorial.
OK -- time for someone to come up with word for "Itererable that isn't an Iterator" -- I"d start using it :-)
People used to loosely use “collection” for this, back before it was defined to mean “sized container”, but that no longer works.
Maybe we need to come up with a word that can’t possibly have any existing meaning to anyone, like Standard Oil did with “Exxon”.