On Dec 12, 2014, at 16:40, Chris Barker <chris.barker@noaa.gov> wrote:

On Fri, Dec 12, 2014 at 3:22 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
1) It's not clear what is meant by an "iterator" -- when we use the term is seems like we are talking about a type, when we are really talking about "anything that conforms to the iterator protocol", so I'm going to introduce a new term: TIIP (Type Implementing the Iterator Protocol) -- maybe that's too cute, but role with it for now.

When you're writing actual code, you can test this with isinstance(collections.abc.Iterator). Of course ABCs don't _perfectly_ cover their related protocols (in this case, if you create a type that has __iter__ and __next__ but __iter__ doesn't return self--or, of course, if you just register some random type with Iterator explicitly--you've created a subclass of Iterator that isn't a subtype of the iterator protocol). But I think it still makes sense to use Iterator as shorthand for "type that subclasses Iterator" with the implied "is an actual subtype of the semantic type intended by the Iterator class".

this issue here is that inteh PEP, and in this list, it seems "iterator" was used to describe classes with __init__ and __next__ methods, AS APPOSED to the things returned from functions with a yield in them...

But the thing returned by a function without yield in it is an instance of the built-in class generator, which is a subtype of Iterator.

Are you trying to make a distinction between iterator _types_ and iterator type _instances_? If so, TIIP doesn't seem to help very much.

and:

In [12]: g = (i for i in range(10))

In [13]: isinstance(it, collections.abc.Iterator)
Out[13]: True

and 

In [15]: def gf():
   ....:     yield 1
   ....:     yield 2

In [16]: gen = gf()

In [17]: isinstance(gen, collections.abc.Iterator)
Out[17]: True

So generators ARE iterators, but his definition and yet the contrast was being made....

Yes, there was some unfortunate wording in the earlier version that Guido already acknowledged and promised to fix well before your message.

This kind of shorthand is used regularly in discussing types in every OO language, not just Python.

sure, but Python is dynamically types, so "conforms to a protocol" not at all teh same is "isinstance", even though ABCS have made this closer...

The whole point of ABCs is to allow you to define protocols in-language. Other dynamic OO languages like Smalltalk and ObjC have similar concepts.

In Python, the term "Iterator" is just as consistent and meaningful as in all these other languages. The fact that some people confuse iterables and iterators isn't a reason to abandon this simplicity.

actually, the confusion between iterables and iterators want the issue I as trying to address -- but the confusion with a sentence like

"Under this proposal, generators and iterators would be distinct, but related, concepts"

That has been removed from the PEP -- I think it's more clean now in any case.

But yes, I could have written all that and stuck with plain old "iterator" instead of making up "TIIP"

Especially since it doesn't even help to solve the problem--as we've just seen in this very message I'm replying to, it's just as easy for someone to mistakenly use TIIP to describe "range" as it is for them to mistakenly use "Iterator".

My bad -- typing too fast! And this was never about the itterable vs iterator distinction anyway.
 
(In fact, it's arguably worse, because what would you call an Iterable under the same naming scheme but Type Implementing Iterable Protocol, or TIIP?)

I was not trying to mingle iterable and iterator -- really I wan't :-)

 
The things we need to be clear about here are the things that _dont't_ have an official name. In particular, the thing that's built from calling a generator function or evaluating a generator expression and used by the generator.

now I am confused:

In [18]: g = ( i for i in range(10) )

In [19]: type(g)
Out[19]: generator

how is that not a "generator"?

You've skipped the "used by the generator" part of that sentence.

Of course g is an instance of generator (and therefore also an iterator).

But you're not defining the generator type here--that already exists as a builtin type. What you're defining is a thing made up of a code object and a frame, which is used by that generator instance to do its generating. That thing is not a generator, or a generator type (or an iterator instance or type), or a __next__ method, or anything else with a name.

(I don't know if that's the thing Guido was trying to describe as not an iterator, but I don't think that's too important, since he's already acknowledged that the distinction he was trying to make isn't important anyway.)