Re: Iterators, iterables and special objects

On 25/07/2020 06:35, Random832 wrote: On Tue, Jul 21, 2020, at 15:54, Terry Reedy wrote: The transformers should be once-through iterators because they can be passed once-through interators. I suppose one could make them iterables and add an attribute 'pristine' set to True in __init__ and Fals

Re: Iterators, iterables and special objects

On Fri, Jul 24, 2020, at 14:42, Chris Angelico wrote: > And then someone will ask why you can't subscript a map object if the > underlying object could be subscripted, etc, etc, etc. It's not meant > to be a transparent layer over the object; it's just an iterator - > basically equivalent to: > >

Re: Iterators, iterables and special objects

On Thu, Jul 23, 2020, at 05:14, Peter Slížik wrote: > > Works in what way? You can't use it in a 'for' loop if it doesn't > > define __iter__. > > > > class Iterable: > def __iter__(self): > return Iterator(...) > > class Iterator: > def __next__(self): > return > >

Re: Iterators, iterables and special objects

On Sat, Jul 25, 2020 at 4:37 AM Random832 wrote: > > On Tue, Jul 21, 2020, at 15:54, Terry Reedy wrote: > > The transformers should be once-through iterators because they can be > > passed once-through interators. I suppose one could make them iterables > > and add an attribute 'pristine' set to

Re: Iterators, iterables and special objects

On Tue, Jul 21, 2020, at 15:54, Terry Reedy wrote: > The transformers should be once-through iterators because they can be > passed once-through interators. I suppose one could make them iterables > and add an attribute 'pristine' set to True in __init__ and False in > __iter__, but why have 2

Re: Iterators, iterables and special objects

On 7/23/2020 5:14 AM, Peter Slížik wrote: Works in what way? You can't use it in a 'for' loop if it doesn't define __iter__. class Iterable: def __iter__(self): return Iterator(...) class Iterator: def __next__(self): return # No __iter__ here. # I've j

Re: Iterators, iterables and special objects

> Works in what way? You can't use it in a 'for' loop if it doesn't > define __iter__. > class Iterable: def __iter__(self): return Iterator(...) class Iterator: def __next__(self): return # No __iter__ here. # I've just forgotten to def it. With this setup, usi

Re: Iterators, iterables and special objects

On Thu, Jul 23, 2020 at 5:55 PM Peter Slížik wrote: > Moreover, some tutorial authors make it even more difficult with using the > terms iterator and iterable interchangeably. A notorious example is this > wiki: > https://wiki.python.org/moin/Iterator > > It says: > > *Here is an *iterator* that r

Re: Iterators, iterables and special objects

On Thu, Jul 23, 2020 at 5:55 PM Peter Slížik wrote: > > Python's design that iter(iterator) is iterator is extremely handy. > > > > Yes, but it has the unfortunate consequence that an iterator is expected > to define > > def __iter__(self):return self > > which I saw people *not* doing, suppo

Re: Iterators, iterables and special objects

> The view are iterables. They can be iterated more than once and used in > other operations. > > The transformers should be once-through iterators because they can be > passed once-through interators. This is important, thank you for pointing it out. > Python's design that iter(iterator) is

Re: Iterators, iterables and special objects

On 7/21/20 9:32 PM, Peter Slížik wrote: Hi list, two related questions: 1. Why do functions used to iterate over collections or dict members return specialized objects like type(dict.keys()) -> class 'dict_keys' type(dict.values()) -> class 'dict_values' type(dict.items()) -> class 'dict_items'

Re: Iterators, iterables and special objects

On 7/21/2020 5:32 AM, Peter Slížik wrote: Hi list, two related questions: 1. Why do functions used to iterate over collections or dict members return specialized objects like type(dict.keys()) -> class 'dict_keys' type(dict.values()) -> class 'dict_values' type(dict.items()) -> class 'dict_item

Re: Iterators of iterators

On Fri, Nov 16, 2018 at 8:01 AM Steve Keller wrote: > > I wonder why iterators do have an __iter__() method? I thought > iterable objects would have an __iter__() method (but no __next__()) > to create an iterator for it, and that would have the __next__() > method but no __iter__(). > > $ py

Re: Iterators membership testing

On 2015-08-09 19:24, Chris Angelico wrote: > That's exactly right. The only way for the interpreter to handle > 'in' on an iterator is something like this: > > def contains(iter, obj): > for val in iter: > if val == obj: return True > return False Which can nicely be written as

Re: Iterators membership testing

On 09/08/2015 12:30, Laura Creighton wrote: Maybe add something about this here? https://docs.python.org/2/tutorial/classes.html#iterators Laura Better still https://docs.python.org/3/tutorial/classes.html#iterators -- My fellow Pythonistas, ask not what our language can do for you, ask what

Re: Iterators membership testing

On 09/08/2015 14:11, Chris Angelico wrote: On Sun, Aug 9, 2015 at 11:09 PM, Tim Chase wrote: On 2015-08-09 19:24, Chris Angelico wrote: That's exactly right. The only way for the interpreter to handle 'in' on an iterator is something like this: def contains(iter, obj): for val in iter:

Re: Iterators membership testing

On 2015-08-09 19:24, Chris Angelico wrote: > That's exactly right. The only way for the interpreter to handle > 'in' on an iterator is something like this: > > def contains(iter, obj): > for val in iter: > if val == obj: return True > return False Which can nicely be written as

Re: Iterators membership testing

On Sun, Aug 9, 2015 at 11:09 PM, Tim Chase wrote: > On 2015-08-09 19:24, Chris Angelico wrote: >> That's exactly right. The only way for the interpreter to handle >> 'in' on an iterator is something like this: >> >> def contains(iter, obj): >> for val in iter: >> if val == obj: return

Re: Iterators membership testing

Maybe add something about this here? https://docs.python.org/2/tutorial/classes.html#iterators Laura -- https://mail.python.org/mailman/listinfo/python-list

Re: Iterators membership testing

On Sun, Aug 9, 2015 at 9:00 PM, Pierre Quentel wrote: >> The trap you're seeing here is that iterating over an iterator always >> consumes it, but mentally, you're expecting this to be iterating over >> a new instance of the same sequence. > > No, I just tried to apply what I read in the docs : >

Re: Iterators membership testing

> The trap you're seeing here is that iterating over an iterator always > consumes it, but mentally, you're expecting this to be iterating over > a new instance of the same sequence. No, I just tried to apply what I read in the docs : 1. I have y = A(10) which is an instance of a class which doe

Re: Iterators membership testing

On Sun, Aug 9, 2015 at 7:55 PM, Pierre Quentel wrote: > Thanks for the explanation. I understand that an iterator can't test > membership any other way, but I'm still worried about how the documentation > explains it. Reading it, I naively expected that an iterator which produces > the integer

Re: Iterators membership testing

Le dimanche 9 août 2015 11:25:17 UTC+2, Chris Angelico a écrit : > On Sun, Aug 9, 2015 at 7:06 PM, Pierre Quentel > wrote: > > "For user-defined classes which do not define __contains__() but do define > > __iter__(), x in y is true if some value z with x == z is produced while > > iterating over

Re: Iterators membership testing

On Sun, Aug 9, 2015 at 7:06 PM, Pierre Quentel wrote: > "For user-defined classes which do not define __contains__() but do define > __iter__(), x in y is true if some value z with x == z is produced while > iterating over y. If an exception is raised during the iteration, it is as if > in raised

Re: iterators and continuing after a StopIteration

Roald de Vries wrote: Hi all, I have a list that I'm iterating over, and during the iteration items are appended. Moreover, it is iterated over in two nested loops. If the inner loop comes to the end, I want the outer loop to append an item. Is there a way to do this? Because once an iterato

Re: iterators and views of lists

On Dec 20, 12:04 am, Anh Hai Trinh wrote: > chain: > >   sorted(itertools.chain(listagent(x)[::2], listagent(y)[-1:1:-2])) >   [0, 4, 8, 12, 13, 15, 16, 17, 19] > > zip: > >   sorted(itertools.izip(listagent(z)[1::3], listagent(x)[2::3])) >   [(452, 16), (758, 4), (898, 10)] I think I mis-interp

Re: iterators and views of lists

On Fri, 18 Dec 2009 21:10:28 -, Brendan Miller wrote: When I said they are "weak" I meant it in sense that the algorithms writeable against an InputerIterator interface (which is what python's iterator protocol provides) is a proper subset of the algorithms that can be written against a R

Re: iterators and views of lists

On Dec 18, 12:18 pm, "Alf P. Steinbach" wrote: [lots of tangential information snipped] > ...but I don't understand why you're limiting yourself to the STL. Because I believe the vast majority of iterators used in C++ in practice are the ones provided by STL types, therefore I felt a statement ab

Re: iterators and views of lists

On Dec 19, 5:47 am, Bearophile wrote: > It seems you have missed my post, so here it is, more explicitly: > > http://www.boostcon.com/site-media/var/sphene/sphwiki/attachment/2009... Interestingly, my `listagent` can be used as a lazy iterator and thus using itertools we can compose them just l

Re: iterators and views of lists

On 12/19/2009 12:10 AM, Gregory Ewing wrote: Terry Reedy wrote: On the other hand, Python indexes are a form of random access iterator, the top of the hierarchy. The term "random access iterator" seems oxymoronic to me. Iteration is all about operating on things in sequence. If you're accessin

Re: iterators and views of lists

On 12/17/2009 4:44 AM, Francesco Bochicchio wrote: On Dec 16, 1:58 pm, Anh Hai Trinh wrote: You might be interested in this library. You can easily create arbitrary "slice", for example i = mylist>> takei(primes()) will return an iterator over the i

Re: iterators and views of lists

On Fri, Dec 18, 2009 at 2:47 PM, Bearophile wrote: > Brendan Miller: >> I agree though, it doesn't matter to everyone and anyone. The reason I >> was interested was because i was trying to solve some specific >> problems in an elegant way. I was thinking it would be cool to make >> python more usa

Re: iterators and views of lists

Terry Reedy wrote: On the other hand, Python indexes are a form of random access iterator, the top of the hierarchy. The term "random access iterator" seems oxymoronic to me. Iteration is all about operating on things in sequence. If you're accessing elements arbitrarily, then you're not iterat

Re: iterators and views of lists

On Fri, 18 Dec 2009 10:39:15 -0800, Carl Banks wrote: > It is true that Python iterators can't be used to mutate the underlying > structure--if there is actual underlying data structure-- An iterator is a protocol. So long as you have __iter__ and next (or __next__ in Python 3) methods, your cl

Re: iterators and views of lists

Brendan Miller: > I agree though, it doesn't matter to everyone and anyone. The reason I > was interested was because i was trying to solve some specific > problems in an elegant way. I was thinking it would be cool to make > python more usable in programming competitions by giving it its own > por

Re: iterators and views of lists

On 12/18/2009 1:00 AM, Brendan Miller wrote: For the benefit of those of us who aren't C++ programmers, what do its iterators do that Python's don't? It depends on what one means by 'iterator'. Python iterators do not fit in the STL hierarchy. On the other hand, Python indexes are a form of

Re: iterators and views of lists

On Fri, Dec 18, 2009 at 10:39 AM, Carl Banks wrote: > On Dec 17, 10:00 pm, Brendan Miller wrote: >> On Thu, Dec 17, 2009 at 6:44 PM, Steven D'Aprano >> >> wrote: >> > On Thu, 17 Dec 2009 12:07:59 -0800, Brendan Miller wrote: >> >> >> I was thinking it would be cool to make python more usable in

Re: iterators and views of lists

* Carl Banks: On Dec 18, 11:08 am, "Alf P. Steinbach" wrote: * Carl Banks: On Dec 17, 10:00 pm, Brendan Miller wrote: On Thu, Dec 17, 2009 at 6:44 PM, Steven D'Aprano wrote: On Thu, 17 Dec 2009 12:07:59 -0800, Brendan Miller wrote: I was thinking it would be cool to make python more us

Re: iterators and views of lists

On Dec 18, 11:08 am, "Alf P. Steinbach" wrote: > * Carl Banks: > > > > > On Dec 17, 10:00 pm, Brendan Miller wrote: > >> On Thu, Dec 17, 2009 at 6:44 PM, Steven D'Aprano > > >> wrote: > >>> On Thu, 17 Dec 2009 12:07:59 -0800, Brendan Miller wrote: > I was thinking it would be cool to make p

Re: iterators and views of lists

On 12/18/2009 7:07 AM, Brendan Miller wrote: As for copying pointers not taking much time... that depends on how long the list is. if you are working with small sets of data, you can do almost anything and it will be efficient. However, if you have megabytes or gigabytes of data (say you are work

Re: iterators and views of lists

* Carl Banks: On Dec 17, 10:00 pm, Brendan Miller wrote: On Thu, Dec 17, 2009 at 6:44 PM, Steven D'Aprano wrote: On Thu, 17 Dec 2009 12:07:59 -0800, Brendan Miller wrote: I was thinking it would be cool to make python more usable in programming competitions by giving it its own port of the

Re: iterators and views of lists

On Dec 17, 10:00 pm, Brendan Miller wrote: > On Thu, Dec 17, 2009 at 6:44 PM, Steven D'Aprano > > wrote: > > On Thu, 17 Dec 2009 12:07:59 -0800, Brendan Miller wrote: > > >> I was thinking it would be cool to make python more usable in > >> programming competitions by giving it its own port of th

Re: iterators and views of lists

On Dec 18, 3:07 am, Brendan Miller wrote: > Well, it doesn't really need to be any slower than a normal list. You > only need to use index and do extra additions because it's in python. > However, if listagent were written in C, you would just have a pointer > into the contents of the original li

Re: iterators and views of lists

On Thu, Dec 17, 2009 at 6:44 PM, Steven D'Aprano wrote: > On Thu, 17 Dec 2009 12:07:59 -0800, Brendan Miller wrote: > >> I was thinking it would be cool to make python more usable in >> programming competitions by giving it its own port of the STL's >> algorithm library, which needs something alon

Re: iterators and views of lists

On Thu, 17 Dec 2009 12:07:59 -0800, Brendan Miller wrote: > I was thinking it would be cool to make python more usable in > programming competitions by giving it its own port of the STL's > algorithm library, which needs something along the lines of C++'s more > powerful iterators. For the benefi

Re: iterators and views of lists

On Thu, Dec 17, 2009 at 8:41 AM, Anh Hai Trinh wrote: >> I have a couple of thoughts: >> 1. Since [:] by convention already creates a copy, it might violate >> people's expectations if that syntax were used. > > Indeed, listagent returns self on __getitem__[:]. What I meant was > this: > >  x = [0

Re: iterators and views of lists

> I have a couple of thoughts: > 1. Since [:] by convention already creates a copy, it might violate > people's expectations if that syntax were used. Indeed, listagent returns self on __getitem__[:]. What I meant was this: x = [0, 1, 2, 3, 4, 5, 6, 7] a = listagent(x)[::2] a[:] = listagent

Re: iterators and views of lists

On Wed, Dec 16, 2009 at 12:38 PM, Anh Hai Trinh wrote: > On Dec 16, 2:48 pm, Brendan Miller wrote: > >> No, that's what I'm getting at... Most of the existing mutating >> algorithms in python (sort, reverse) operate over entire collections, >> not partial collections delimited by indexes... which

Re: iterators and views of lists

On Dec 16, 2:48 pm, Brendan Miller wrote: > No, that's what I'm getting at... Most of the existing mutating > algorithms in python (sort, reverse) operate over entire collections, > not partial collections delimited by indexes... which would be really > awkward anyway. Ok it can be done! The cod

Re: iterators and views of lists

On Wed, Dec 16, 2009 at 4:16 AM, Paul Rudin wrote: > Steven D'Aprano writes: > > >> I'm sympathetic to your request for list views. I've often wanted some >> way to cleanly and neatly do this: >> >> for item in seq[1:]: >>     process(item) >> >> without making an unnecessary copy of almost all o

Re: iterators and views of lists

On Dec 16, 1:58 pm, Anh Hai Trinh wrote: > > You might be interested in this library stream>. > > You can easily create arbitrary "slice", for example > >   i = mylist >> takei(primes()) > > will return an iterator over the items of mylist with a prime number > ind

Re: iterators and views of lists

On Wed, Dec 16, 2009 at 5:39 AM, Steven D'Aprano < st...@remove-this-cybersource.com.au> wrote: > for item in seq[1:]: >process(item) > > without making an unnecessary copy of almost all of seq. > I use the following idiom: for i in range(1, len(seq)): process(seq[i]) Alternately, if I'm

Re: iterators and views of lists

On Wed, Dec 16, 2009 at 7:33 AM, Peter Otten <__pete...@web.de> wrote: > islice() could be changed to special-case lists and tuples, but that feels > a > bit unclean. > How about special-casing objects that implement collections.Sequence? -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterpris

Re: iterators and views of lists

On Dec 15, 11:48 pm, Brendan Miller wrote: > I was thinking you'd want something like random access iterators in > c++, or pointers in c, to write typical in place algorithmic code. To > me, something like non-copying slices (maybe you'd call it a list > view?) would seem functionally similar and

Re: iterators and views of lists

Paul Rudin wrote: > Steven D'Aprano writes: > > >> I'm sympathetic to your request for list views. I've often wanted some >> way to cleanly and neatly do this: >> >> for item in seq[1:]: >> process(item) >> >> without making an unnecessary copy of almost all of seq. >> > > I don't know how

Re: iterators and views of lists

On Dec 16, 10:39 am, Brendan Miller wrote: > I was trying to reimplement some of the c++ library of generic > algorithms in c++ in python, but I was finding that this is > problematic to do this in a generic way because there isn't any > equivalent of c++'s forward iterators, random access iterato

Re: iterators and views of lists

Steven D'Aprano writes: > I'm sympathetic to your request for list views. I've often wanted some > way to cleanly and neatly do this: > > for item in seq[1:]: > process(item) > > without making an unnecessary copy of almost all of seq. > I don't know how it's implemented - but presumably i

Re: iterators and views of lists

On Tue, 15 Dec 2009 23:48:04 -0800, Brendan Miller wrote: > On Tue, Dec 15, 2009 at 9:09 PM, Terry Reedy wrote: >> On 12/15/2009 10:39 PM, Brendan Miller wrote: >>> I'm wondering if anyone has done work towards creating more powerful >>> iterators for python, or creating some more pythonic equiva

Re: iterators and views of lists

Brendan Miller: > Currently people slice and dice with well... slices, but those are > copying, so if you want to operate over part of a range you make a > copy, perform the operation, then copy the results back in. > > I was thinking you'd want something like random access iterators in > c++, or p

Re: iterators and views of lists

On Tue, Dec 15, 2009 at 9:09 PM, Terry Reedy wrote: > On 12/15/2009 10:39 PM, Brendan Miller wrote: >> I'm wondering if anyone has done work towards creating more powerful >> iterators for python, or creating some more pythonic equivalent. > > For sequences, integer indexes let you do anything you

Re: iterators and views of lists

On 12/15/2009 10:39 PM, Brendan Miller wrote: I was trying to reimplement some of the c++ library of generic algorithms in c++ in python, but I was finding that this is problematic to do this in a generic way because there isn't any equivalent of c++'s forward iterators, random access iterators,

Re: Iterators

On Fri, Oct 16, 2009 at 8:22 AM, Duncan Booth wrote: > Chris Rebert wrote: > >> Essentially, file iterators are dumb and don't keep track of where in >> the file the next line starts, instead relying on their associated >> file object to keep track of the current position in the file; the >> iter

Re: Iterators

On Fri, Oct 16, 2009 at 9:24 AM, Harald Kraemer wrote: > Stephen Hansen wrote: > Nothing 'dumb' or 'smart' about it: it is simply that a file object is > >> already an iterator. Trying to create an iterator from an existing >>> iterator >>> in Python never duplicates the iterator. >>> >>> >>> f

Re: Iterators

Stephen Hansen wrote: On Fri, Oct 16, 2009 at 5:22 AM, Duncan Booth wrote: Chris Rebert wrote: > Essentially, file iterators are dumb and don't keep track of where in > the file the next line starts, [snip] Nothing 'dumb' or 'smart' about it: it is simply that a file object is alread

Re: Iterators

In article , Duncan Booth wrote: >Chris Rebert wrote: >> >> Essentially, file iterators are dumb and don't keep track of where in >> the file the next line starts, instead relying on their associated >> file object to keep track of the current position in the file; the >> iterator's state is lit

Re: Iterators

On Fri, Oct 16, 2009 at 5:22 AM, Duncan Booth wrote: > Chris Rebert wrote: > > > Essentially, file iterators are dumb and don't keep track of where in > > the file the next line starts, > [snip] > > Nothing 'dumb' or 'smart' about it: it is simply that a file object is > already an iterator. Tr

Re: Iterators

Chris Rebert wrote: > Essentially, file iterators are dumb and don't keep track of where in > the file the next line starts, instead relying on their associated > file object to keep track of the current position in the file; the > iterator's state is little more than a reference to its associate

Re: Iterators

On Fri, Oct 16, 2009 at 2:24 AM, Kelson Folkvard Braaten ZAWACK wrote: > Recently I was iterating through both a list and a file and I noticed a > difference in behavior.  When I create an iterator for a list by calling > iter(list_name) and then call the iterators  next method I get the first > e

Re: Iterators: Would "rewind" be a good idea?

> My knowledge of Python's iterators is kind of sketchy, so I may have missed > something. The only thing a python iterator really is is something that supports a next()-method and will raise a StopIteration-Exception in case of exhaustion. So - nobody stops you from introducing an object like

Re: Iterators: Would "rewind" be a good idea?

Roy Smith wrote: > Edward Elliott <[EMAIL PROTECTED]> wrote: >> This is why the C++ STL has independent forward and backward iterator >> types. > > Let me see if I can paraphrase the difference between the Python design > philosophy and the C++ design philosophy about most things. Python says, >

Re: Iterators: Would "rewind" be a good idea?

Edward Elliott <[EMAIL PROTECTED]> wrote: > This is why the C++ STL has independent forward and backward iterator types. Let me see if I can paraphrase the difference between the Python design philosophy and the C++ design philosophy about most things. Python says, "Let's make things simple eno

Re: Iterators: Would "rewind" be a good idea?

Heiko Wundram wrote: > But, think of the following: what if the iterator computes the values at > runtime, and you're not iterating over a "predefined" list of some sort? > Do you want the machinery to store the state of the iterator at every > earlier point in time (sometimes this may not even be

Re: Iterators: Would "rewind" be a good idea?

Am Sonntag 21 Mai 2006 21:43 schrieb Charles D Hixson: > I was reading through old messages in the list and came up against an > idea that I thought might be of some value: > "Wouldn't it be a good idea if one could "rewind" an iterator?" > Not stated in precisely those terms, perhaps, but that's t

Re: Iterators from urllib2

Joshua Ginsberg wrote: > >>> dir(ifs) > ['__doc__', '__init__', '__iter__', '__module__', '__repr__', 'close', > 'fileno', 'fp', 'geturl', 'headers', 'info', 'next', 'read', > 'readline', 'readlines', 'url'] > > Yep. But what about in my code? I modify my code to print dir(ifs) > before cr

Re: Iterators from urllib2

Joshua Ginsberg wrote: > I'm a bit baffled by something... > > In a script I wrote, I have defined a function that runs > urllib2.urlopen() on a urllib2.Request object and returns the file-like > object. The code that calls this function attempts to build a > csv.DictReader object based on t

Re: iterators instead of callbacks.

Antoon Pardon wrote: I'm thinking about the FTP-lib now where iterator equivallents of > retrbinary and retrlines methods may be more easily usable then the > current versions with a callback. So I was wondering, are such transformations in the pipeline somewhere? Maybe that should be a Python 3.0