reseting an iterator

[norseman]

Terry Reedy wrote:
> Jan wrote:
>> Wouldn't it be easy for Python to implement generating functions so
>> that the iterators they return are equipped with a __reset__() method?
> 
> No.  Such a method would have to poke around in the internals of the 
> __next__ function in implementation specific ways.  The values used to 
> initialize that function might have changed, so 'reset' would have to be 
> carefully defined.
> 
> def squares():
>   start = int(input("enter starting int:"))
>   stop  = int(input("enter stopping int"))
>   for i in range(start,stop):
>     yield i*i
> 
> What does 'reset' mean here?

I don't understand.  Why would one use a reset here in the first place? 
One simply re-runs this.  The output could be collected into a list, 
which one might want to reset, re-list.
bad example?


> 
>> Here is the context of this question.
>>
>> Python documentation defines  a "iterator" as an object ITERATOR
>> having methods __next__() and __iter__() such that the call
>> ITERATOR.__iter__() returns the object itself, 
> 
> This is so that 'iter(iterator) is iterator', 

You would do well to clarify the previous line.
To me it is the same as   a face is a face
function(x) is x      six of one, half dozen of the other
gobble-d-goop, double talk     so what?
Not trying to pick a fight - just pointing out the need for some 
clarity.  Had a math teacher that proclaimed any function(x) that only 
returned x was (hummm can't print that here).  Something like useless.


so that functions can take
> either an interable or iterator as an argument and proceed without 
> checking which it got.

OK.

> 
>> and once a call ITERATOR. __next__() raises StopIteration every
>  >  such subsequent call does the same.
> 

if it can't be restarted (serial line input) then don't, else do.
serial line, ethernet, etc are basically pipes. But a list itself can be 
re-wound, be it a file on disk, something in memory, on tape -- whatever

may have to reach back past the 'pipe' to the 'iterator' there to 
restart but being able to restart (elegantly) restartables is the point.

> After returning objects for some number of calls, which might be unbounded.
> 
> The protocol is basically one method with defined behavior.  It is 
> intentionally minimal so it can be used as the universal within-Python 
> object stream protocol.  Multiple ways of getting interators is in line 
> with this purpose.

I think clarity is also needed here.  Different disciplines will 
interpret the above differently. Stream means river, channel, pipe, 
singular direction to me.  Once the water flows past there is no hope of 
getting those molecules back in same order.  A list of things in a 
container (variable or file) is not a stream and can be rewound. The 
whole concept of random access hinges on this.
To me this boils down to two distinct concepts.
   one being stream as in here it comes there it goes, never to return.
     The stream is not rewindable. The container you put it in might be.
   one being sequential reading of finite number of randomly accessible
     things.  This being inherently rewindable.
Testing which is simple enough and can set the ability to rewind. 
Having it 'built-in' will reduce the problems generated by another 
'do-it-yourself' design by person that may or may not have thought 
things out.  The old - "I took the carburettor off the Olds but it 
doesn't work on my Hugo. Can you help me?" would be avoided.
Really - rewind is better if it is builtin and preforms where it should.
The docs should explain what will or will not happen and why. 
Preferably in plain language. :)



In short: are you telling us the reset() can't do in background the 
exact same thing that the docs tell the users to do?  It's a lot simpler 
to move file descriptors and pointers from the inside.

I often get so close to things I forget to look up too.


> 
> Terry Jan Reedy
>