"Iterator" isn't quite right (you get back an iterable, from which Python implicitly creates an iterator when you do something that requires iteration; Python iterators are generally designed to be idempotent, so they often get confused for the underlying iterable), and "cast" is definitely not right (the underlying iterable is consumed, as the author then acknowledges). But I really don't think the goal here is to "sound more erudite"; a proper explanation wouldn't really be any shorter or simpler.
There was an angry comment left at the blog itself about the piece being too long and flowery. Tone notwithstanding, I agree. The story of Yteria in a world of word theft is simply distracting, and does little to justify an exercise which hardly needs justification in the first place. The author seems to be self-marketing a book on this style of "narrative technical writing" which supposedly aims not to be boring. But when I notice that someone is writing this way, I just skip to the code samples to see how they lay out the lesson. You don't need a story like this just to introduce metaphor and hypotheticals ("suppose you wanted to do this with X restriction / Y new requirement").
"Therefore, you'll need to cast the iterator that's returned to a list or a tuple, say, to view its contents:"
what the hell is this nonsense? This isn't C and attempting to borrow words to make it sound more erudite only serves to confuse people.
"Iterator" isn't quite right (you get back an iterable, from which Python implicitly creates an iterator when you do something that requires iteration; Python iterators are generally designed to be idempotent, so they often get confused for the underlying iterable), and "cast" is definitely not right (the underlying iterable is consumed, as the author then acknowledges). But I really don't think the goal here is to "sound more erudite"; a proper explanation wouldn't really be any shorter or simpler.
There was an angry comment left at the blog itself about the piece being too long and flowery. Tone notwithstanding, I agree. The story of Yteria in a world of word theft is simply distracting, and does little to justify an exercise which hardly needs justification in the first place. The author seems to be self-marketing a book on this style of "narrative technical writing" which supposedly aims not to be boring. But when I notice that someone is writing this way, I just skip to the code samples to see how they lay out the lesson. You don't need a story like this just to introduce metaphor and hypotheticals ("suppose you wanted to do this with X restriction / Y new requirement").
yeah it was a bullshit piece all around, but this sentence really stood out.