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
--
http://mail.python.org/mailman/listinfo/python-list
