Re: Generators, generator expressions, and loops

Steve, On 17/11/18 03:52, Steve Keller wrote: I have looked at generators, generator expressions, and iterators and I try to get more familiar with these. 1. How would I loop over all (with no upper bound) integers or all powers of two, for example? In C it would be for (int i = 0; ; i++)

Re: Re: Generators, generator expressions, and loops

Lovely, succinct answers. On 17/11/2018 2:44 AM, Ian Kelly wrote: On Fri, Nov 16, 2018 at 7:57 AM Steve Keller wrote: I have looked at generators, generator expressions, and iterators and I try to get more familiar with these. 1. How would I loop over all (with no upper bound) integers or al

Re: Generators, generator expressions, and loops

> On 16 Nov 2018, at 14:54, Steve Keller wrote: > More elegant are generator expressions but I cannot think of a way > without giving an upper limit: > >for i in (2 ** i for i in range(100)): >... > > which looks ugly. Also, the double for-loop (and also the two loops > in the

Re: Generators, generator expressions, and loops

Try itertools.count() . On Fri, Nov 16, 2018 at 12:08 PM Steve Keller wrote: > Cancel ill-formated article > -- > https://mail.python.org/mailman/listinfo/python-list > -- Santiago Basulto.- Co-founder @ rmotr.com -- https://m

Re: Generators, generator expressions, and loops

On Fri, Nov 16, 2018 at 7:57 AM Steve Keller wrote: > > I have looked at generators, generator expressions, and iterators and > I try to get more familiar with these. > > 1. How would I loop over all (with no upper bound) integers or all > powers of two, for example? > > In C it would be > >fo

Re: generators as decorators simple issue

On Wed, Sep 12, 2012 at 4:22 AM, pyjoshsys wrote: > The output is still not what I want. Now runtime error free, however the > output is not what I desire. [SNIP] > class Trial(object): > '''class to demonstrate with''' > def __init__(self): > object.__init__(self) > sel

Re: generators as decorators simple issue

so decorators only pass the object and not any instance of the object as the implied argument? Is this right? The idea was to use @setname instead of instance.SetName(instance.__name__). I thought decorators would do this, but it seems not. -- http://mail.python.org/mailman/listinfo/pyth

Re: generators as decorators simple issue

On Wed, 12 Sep 2012 03:22:31 -0700 (PDT), pyjoshsys wrote: The output is still not what I want. Now runtime error free, however the output is not what I desire. def setname(cls): '''this is the proposed generator to call SetName on the object''' try: cls.SetName(cls.__name

Re: generators as decorators simple issue

The output is still not what I want. Now runtime error free, however the output is not what I desire. def setname(cls): '''this is the proposed generator to call SetName on the object''' try: cls.SetName(cls.__name__) except Exception as e: print e finally:

Re: generators as decorators simple issue

Am 12.09.2012 04:28 schrieb j.m.dagenh...@gmail.com: I'm trying to call SetName on an object to prevent me from ever having to call it explictly again on that object. Best explained by example. def setname(cls): '''this is the proposed generator to call SetName on the object''' try:

Re: generators as decorators simple issue

On Sep 12, 12:28 pm, j.m.dagenh...@gmail.com wrote: > def setname(cls): >     '''this is the proposed generator to call SetName on the object''' >     try: >         cls.SetName(cls.__name__) >     finally: >         yield cls A generator is (basically) a callable that acts like an iterator. You'd

Re: generators as decorators simple issue

On Wednesday, 12 September 2012 07:58:10 UTC+5:30, pyjoshsys wrote: > I'm trying to call SetName on an object to prevent me from ever having to > call it explictly again on that object. Best explained by example. > [snip] In your decorator, you are using `yield cls` - it should be `return cls` 99

Re: Generators and propagation of exceptions

On Apr 8, 3:47 pm, r wrote: > I'm already making something like this (that is, if I understand you > correctly). In the example below (an "almost" real code this time, I > made too many mistakes before) all the Expressions (including the > Error one) implement an 'eval' method that gets called by

Re: Generators and propagation of exceptions

On Apr 8, 12:47 pm, r wrote: > Anyway, thank you all for helping me out and bringing some ideas to > the table. I was hoping there might be some pattern specifically > designed for thiskind of job (exception generators anyone?), which > I've overlooked. If not anything else, knowing that this isn'

Re: Generators and propagation of exceptions

On Sat, Apr 9, 2011 at 3:22 AM, Raymond Hettinger wrote: > > You could just let the exception go up to an outermost control-loop > without handling it at all on a lower level.  That is what exceptions > for you: terminate all the loops, unwind the stacks, and propagate up > to some level where the

Re: Generators and propagation of exceptions

r wrote: The code above implements an interactive session (a REPL). Therefore, what I'd like to get is an error information printed out at the output as soon as it becomes available. Couple ideas: 1) Instead of yielding the error, call some global print function, then continue on; or 2) Col

Re: Generators and propagation of exceptions

On Apr 8, 8:55 am, r wrote: > I had a problem for which I've already found a "satisfactory" > work-around, but I'd like to ask you if there is a better/nicer > looking solution. Perhaps I'm missing something obvious. > > The code looks like this: > > stream-of-tokens = token-generator(stream-of-ch

Re: Generators and propagation of exceptions

Terry, Ian, thank you for your answers. On Sat, Apr 9, 2011 at 1:30 AM, Terry Reedy wrote: [...] > According to the above, that should be stream-of-parsed-expressions. Good catch. > The question which you do not answer below is what, if anything, you want to > do with error? If nothing, just pa

Re: Generators and propagation of exceptions

On Apr 8, 8:55 am, r wrote: > I had a problem for which I've already found a "satisfactory" > work-around, but I'd like to ask you if there is a better/nicer > looking solution. Perhaps I'm missing something obvious. > > The code looks like this: > > stream-of-tokens = token-generator(stream-of-ch

Re: Generators and propagation of exceptions

On 4/8/2011 11:55 AM, r wrote: I had a problem for which I've already found a "satisfactory" work-around, but I'd like to ask you if there is a better/nicer looking solution. Perhaps I'm missing something obvious. The code looks like this: stream-of-tokens = token-generator(stream-of-characters

Re: Generators and propagation of exceptions

On Fri, Apr 8, 2011 at 9:55 AM, r wrote: > I had a problem for which I've already found a "satisfactory" > work-around, but I'd like to ask you if there is a better/nicer > looking solution. Perhaps I'm missing something obvious. > > The code looks like this: > > stream-of-tokens = token-generator

Re: Generators.

On 12/9/2009 3:52 AM, Jorge Cardona wrote: 2009/12/8 Lie Ryan: First, I apologize for rearranging your message out of order. Theoretically yes, but the semantic of generators in python is they work on an Iterable (i.e. objects that have __iter__), instead of a Sequence (i.e.. objects that have

Re: Generators.

2009/12/8 Lie Ryan : > First, I apologize for rearranging your message out of order. > > On 12/8/2009 5:29 AM, Jorge Cardona wrote: islice execute the function at the generator and drop the elements that aren't in the slice. I found that pretty weird, the way that i see generato

Re: Generators.

2009/12/7 Taylor : > On Dec 7, 1:29 pm, Jorge Cardona wrote: >> 2009/12/7 Lie Ryan : >> >> >> >> > On 12/7/2009 7:22 AM, Jorge Cardona wrote: >> >> >> Hi, >> >> >> I was trying to create a function that receive a generator and return >> >> a list but that each elements were computed in a diferent

Re: Generators.

First, I apologize for rearranging your message out of order. On 12/8/2009 5:29 AM, Jorge Cardona wrote: islice execute the function at the generator and drop the elements that aren't in the slice. I found that pretty weird, the way that i see generators is like an association between and indexi

Re: Generators.

On Dec 7, 1:29 pm, Jorge Cardona wrote: > 2009/12/7 Lie Ryan : > > > > > On 12/7/2009 7:22 AM, Jorge Cardona wrote: > > >> Hi, > > >> I was trying to create a function that receive a generator and return > >> a list but that each elements were computed in a diferent core of my > >> machine. I star

Re: Generators.

2009/12/7 Lie Ryan : > On 12/7/2009 7:22 AM, Jorge Cardona wrote: >> >> Hi, >> >> I was trying to create a function that receive a generator and return >> a list but that each elements were computed in a diferent core of my >> machine. I start using islice function in order to split the job in a >>

Re: Generators.

On 12/7/2009 7:22 AM, Jorge Cardona wrote: Hi, I was trying to create a function that receive a generator and return a list but that each elements were computed in a diferent core of my machine. I start using islice function in order to split the job in a way that if there is "n" cores each "i"

Re: Generators through the C API

Duncan Booth schrieb: > Lucas P Melo wrote: > >> Hello, I'm a total noob about the C API. Is there any way to create a >> generator function using the C API? I couldn't find anything like the >> 'yield' keyword in it. >> >> Thanks in advance. > > You define a new type with tp_flags including P

Re: Generators through the C API

Lucas P Melo wrote: > Hello, I'm a total noob about the C API. Is there any way to create a > generator function using the C API? I couldn't find anything like the > 'yield' keyword in it. > > Thanks in advance. You define a new type with tp_flags including Py_TPFLAGS_HAVE_ITER. Anything tha

Re: Generators/iterators, Pythonicity, and primes

On Apr 13, 1:39 am, Arnaud Delobelle wrote: > Duncan Booth writes: > > Duncan Booth wrote: > > >> John Posner wrote: > > >>> Do know what in the itertools implementation causes adding a 'if p <= > >>> sqrt(n)' clause to *decrease* performance, while adding a > >>> 'takewhile()' clause *increase

Re: Generators/iterators, Pythonicity, and primes

Duncan Booth writes: > Duncan Booth wrote: > >> John Posner wrote: >> >>> Do know what in the itertools implementation causes adding a 'if p <= >>> sqrt(n)' clause to *decrease* performance, while adding a >>> 'takewhile()' clause *increases* performance? >> >> I haven't timed it, but I woul

Re: Re: Generators/iterators, Pythonicity, and primes

Duncan Booth wrote: > John Posner wrote: > >> Do know what in the itertools implementation causes adding a 'if p <= >> sqrt(n)' clause to *decrease* performance, while adding a >> 'takewhile()' clause *increases* performance? > > I haven't timed it, but I would guess that the takewhile was fa

Re: Re: Re: Generators/iterators, Pythonicity, and primes

Duncan Booth wrote: John Posner wrote: Do know what in the itertools implementation causes adding a 'if p <= sqrt(n)' clause to *decrease* performance, while adding a 'takewhile()' clause *increases* performance? I haven't timed it, but I would guess that the takewhile was faster on

Re: Generators/iterators, Pythonicity, and primes

Duncan Booth writes: > John Posner wrote: > >> Do know what in the itertools implementation causes adding a 'if p <= >> sqrt(n)' clause to *decrease* performance, while adding a >> 'takewhile()' clause *increases* performance? > > I haven't timed it, but I would guess that the takewhile was fas

Re: Re: Generators/iterators, Pythonicity, and primes

John Posner wrote: > Do know what in the itertools implementation causes adding a 'if p <= > sqrt(n)' clause to *decrease* performance, while adding a > 'takewhile()' clause *increases* performance? I haven't timed it, but I would guess that the takewhile was faster only because the sqrt(n) ha

Re: Re: Generators/iterators, Pythonicity, and primes

Arnaud Delobelle wrote: You could do something like this with the help of itertools.ifilter: prime_gen = ifilter( lambda n, P=[]: all(n%p for p in P) and not P.append(n), count(2) ) Formidable! (both the English and French meanings) This is the most elegant, Sieve of Eratos

Re: Generators/iterators, Pythonicity, and primes

John Posner writes: > Inspired by recent threads (and recalling my first message to Python > edu-sig), I did some Internet searching on producing prime numbers using > Python generators. Most algorithms I found don't go for the infinite, > contenting themselves with "list all the primes below a g

Re: Generators/iterators, Pythonicity, and primes

Steven D'Aprano wrote: On Sun, 05 Apr 2009 00:28:17 -0400, Miles wrote: def prime_gen(): ... That's pretty sweet, but we can make it even faster. We can speed things up by incrementing by two instead of one, to avoid pointlessly testing even numbers that we know must fail. We can also speed th

Re: Generators/iterators, Pythonicity, and primes

>> > g = (lambda primes = []: >> > (n for n in count(2) if >> > (lambda x, primes: >> > (primes.append(x) or True >> > if all(x%p for p in primes if p <= sqrt(x)) >> > else False) >> > )(n, primes) >> >

Re: Generators/iterators, Pythonicity, and primes

On 5 Apr., 18:47, John Posner wrote: > Kay Schluehr wrote: > > > That's because it is *one* expression. The avoidance of named > > functions makes it look obfuscated or prodigious. Once it is properly > > dissected it doesn't look that amazing anymore. > > > > Start with: > > > > (n for n i

Re: Generators/iterators, Pythonicity, and primes

Kay Schluehr wrote: > That's because it is *one* expression. The avoidance of named > functions makes it look obfuscated or prodigious. Once it is properly > dissected it doesn't look that amazing anymore. > > Start with: > > (n for n in count(2) if is_prime(n, primes)) > > The is_prime function

RE: Generators/iterators, Pythonicity, and primes

009 8:37 AM To: python-list@python.org Subject: Re: Generators/iterators, Pythonicity, and primes On 5 Apr., 17:14, John Posner wrote: > Kay Schluehr said: > > > g = (lambda primes = []: > > (n for n in count(2) \ > > if > > (lambda n,

Re: Generators/iterators, Pythonicity, and primes

On 5 Apr., 17:14, John Posner wrote: > Kay Schluehr said: > > > g = (lambda primes = []: > > (n for n in count(2) \ > > if > > (lambda n, primes: (n in primes if primes and > n<=primes[-1] \ > > else > > (primes.append(n) or True \ > >

Re: Generators/iterators, Pythonicity, and primes

Kay Schluehr said: > g = (lambda primes = []: > (n for n in count(2) \ > if > (lambda n, primes: (n in primes if primes and n<=primes[-1] \ > else > (primes.append(n) or True \ > if all(n%p for p in primes if p <= sqrt(n)) \ >

Re: Generators/iterators, Pythonicity, and primes

On Sun, 05 Apr 2009 00:28:17 -0400, Miles wrote: > def prime_gen(): > primes = [] > return (primes.append(n) or n for n in count(2) if all(n%p for p > in primes if p<=sqrt(n))) > > That version is only marginally faster than your original version. The > biggest performance penalty is that

Re: Generators/iterators, Pythonicity, and primes

> Question: Is there a way to implement this algorithm using generator > expressions only -- no "yield" statements allowed? Yes. Avoiding the yield statement is easy but one might eventually end up with two statements because one has to produce a side effect on the primes list. However we can use

Re: Generators/iterators, Pythonicity, and primes

On Sat, Apr 4, 2009 at 2:50 PM, John Posner wrote: > Inspired by recent threads (and recalling my first message to Python > edu-sig), I did some Internet searching on producing prime numbers using > Python generators. Most algorithms I found don't go for the infinite, > contenting themselves with "

Re: Generators/iterators, Pythonicity, and primes

John Posner wrote: Inspired by recent threads (and recalling my first message to Python edu-sig), I did some Internet searching on producing prime numbers using Python generators. Most algorithms I found don't go for the infinite, contenting themselves with "list all the primes below a given numb

RE: Generators/iterators, Pythonicity, and primes

Mark Tolonen said: >> p <= sqrt(n) works a little better :^) >> >> -Mark >> Right you are -- I found that bug in my last-minute check, and then I forgot to trannscribe the fix into the email message. Duh -- thanks! -John E-mail message checked by Spyware Doctor (6.0.0.386) Database

Re: Generators/iterators, Pythonicity, and primes

"John Posner" wrote in message news:af9fbcc3a7624599a6f51bad2397e...@amdup... Inspired by recent threads (and recalling my first message to Python edu-sig), I did some Internet searching on producing prime numbers using Python generators. Most algorithms I found don't go for the infinite, cont

Re: Generators and their next() and send() methods

On Nov 18, 5:20 pm, Thomas Mlynarczyk <[EMAIL PROTECTED]> wrote: > Aaron Brady schrieb: > > > And, if you don't intend to use 'myway' on 'listiterator's and such, > > 'send( None )' is equivalent to 'next( )'. > > I didn't know that. But doesn't that impose a restriction somehow? It > makes it impo

Re: Generators and their next() and send() methods

Aaron Brady schrieb: And, if you don't intend to use 'myway' on 'listiterator's and such, 'send( None )' is equivalent to 'next( )'. I didn't know that. But doesn't that impose a restriction somehow? It makes it impossible to send a None to a generator. Greetings, Thomas -- Ce n'est pas pa

Re: Generators and their next() and send() methods

alex23 schrieb: http://www.python.org/dev/peps/pep-0342/ That links to the original proposal to extend the generator behaviour After some searching, I found this as a remark in parentheses: "Introducing a new method instead of overloading next() minimizes overhead for simple next() calls."

Re: Generators and their next() and send() methods

On Nov 16, 3:36 pm, Thomas Mlynarczyk <[EMAIL PROTECTED]> wrote: > Arnaud Delobelle schrieb: > > > If you want to simply 'set' the generator (by which I take you mean > > 'change its state') without without iterating it one step, then what you > > need is a class with an __iter__() method.  Then yo

Re: Generators and their next() and send() methods

On Nov 17, 7:36 am, Thomas Mlynarczyk <[EMAIL PROTECTED]> wrote: > Still, I would like to know why it was decided to > introduce a send() method instead of allowing an argument for next(). Hey Thomas, A great place to gain insight into the reasoning behind changes to Python is the PEPs: http://w

Re: Generators and their next() and send() methods

Arnaud Delobelle schrieb: If you want to simply 'set' the generator (by which I take you mean 'change its state') without without iterating it one step, then what you need is a class with an __iter__() method. Then you can change the state of the object between calls to next(). E.g. class M

Re: Generators and their next() and send() methods

Thomas Mlynarczyk <[EMAIL PROTECTED]> writes: > Hello, > > I was playing around a bit with generators using next() and > send(). And I was wondering why an extra send() method was introduced > instead of simply allowing an argument for next(). > > Also, I find it a bit counter-intuitive that send(

Re: Generators can only yield ints?

On Aug 23, 5:44 am, defn noob <[EMAIL PROTECTED]> wrote: > def letters(): >         a = xrange(ord('a'), ord('z')+1) >         B = xrange(ord('A'), ord('Z')+1) >         while True: >                 yield chr(a) >                 yield chr(B) > > >>> l = letters() > >>> l.next() > > Traceback (mos

Re: Generators can only yield ints?

On Fri, 22 Aug 2008 15:44:15 -0700, defn noob wrote: > def letters(): > a = xrange(ord('a'), ord('z')+1) > B = xrange(ord('A'), ord('Z')+1) > while True: > yield chr(a) > yield chr(B) > > l = letters() l.next() > > Traceback (most recent c

Re: Generators can only yield ints?

On Fri, 22 Aug 2008 15:44:15 -0700 (PDT), defn noob wrote: > def letters(): > a = xrange(ord('a'), ord('z')+1) > B = xrange(ord('A'), ord('Z')+1) > while True: > yield chr(a) > yield chr(B) > > l = letters() l.next() > > Traceback (most recent

Re: Generators can only yield ints?

defn noob: > Any way to get around this? Your code is wrong, this is one of the correct versions: from itertools import izip def letters(): lower = xrange(ord('a'), ord('z')+1) upper = xrange(ord('A'), ord('Z')+1) for lc, uc in izip(lower, upper): yield chr(lc) yield

Re: Generators can only yield ints?

On Fri, Aug 22, 2008 at 6:44 PM, defn noob <[EMAIL PROTECTED]> wrote: > def letters(): >a = xrange(ord('a'), ord('z')+1) >B = xrange(ord('A'), ord('Z')+1) >while True: >yield chr(a) >yield chr(B) > > > TypeError: an integer is required No. Th

Re: Generators in C code

En Tue, 15 May 2007 02:12:40 -0300, Raymond Hettinger <[EMAIL PROTECTED]> escribió: >> I feel I'm out of luck, but if someone could point some way to write a >> generator in C, I'be very grateful! > > Perhaps the code in the itertools module will provide a good example > -- they behave like gene

Re: Generators in C code

On May 14, 9:55 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote: > I feel I'm out of luck, but if someone could point some way to write a > generator in C, I'be very grateful! Perhaps the code in the itertools module will provide a good example -- they behave like generators in many respects e

Re: generators/iterators: filtered random choice

On 15 Sep 2006 19:17:25 -0700, gry@ll.mit.edu wrote: > I want a function (or callable something) that returns a random > word meeting a criterion. I can do it like: > > def random_richer_word(word): > '''find a word having a superset of the letters of "word"''' > if len(set(word) == 26):

Re: generators shared among threads

[Paul Rubin] > It looks to me like you can't have two threads in the same generator: You can't even have one thread in a generator-iterator get away with activating the generator-iterator while it's already active. That's an example in PEP 255: """ Restriction: A generator cannot be resumed w

Re: generators shared among threads

Bryan Olson <[EMAIL PROTECTED]> writes: > I have not found definitive answers in the Python doc. Both > generators and threads keep their own line-of-control, and > how they interact is not clear. It looks to me like you can't have two threads in the same generator: import threading, time

Re: generators shared among threads

[EMAIL PROTECTED] wrote: > You'll get the same result without the lock. I'm not sure what this > indicates. It may show that the contention on the lock and the race > condition on i aren't always problems. It may show that generators, at > least in CPython 2.4, provide thread safety for free. I

Re: generators shared among threads

Bryan, You'll get the same result without the lock. I'm not sure what this indicates. It may show that the contention on the lock and the race condition on i aren't always problems. It may show that generators, at least in CPython 2.4, provide thread safety for free. It does seem to disprove m

Re: generators shared among threads

I just noticed, if you don't define maxsize in _init(), you need to override _full() as well: def _full(self): return False cheers, Jess -- http://mail.python.org/mailman/listinfo/python-list

Re: generators shared among threads

[EMAIL PROTECTED] wrote: > Paul wrote: > >> def f(): >> lock = threading.Lock() >> i = 0 >> while True: >> lock.acquire() >> yield i >> i += 1 >> lock.release() >> >>but it's easy to make mistakes when implementing things like that >>(I'm

Re: generators shared among threads

[EMAIL PROTECTED] (Alex Martelli) writes: > Now, x=ReentrantIterator(itertools.count()) should have all the > properties we want, I think. The locking is thanks of Queue.Queue and > its sweet implementation of the Template Method design pattern. That is very cool, and generally useful enough that

Re: generators shared among threads

In article <[EMAIL PROTECTED]>, Kent Johnson <[EMAIL PROTECTED]> wrote: > Paul Rubin wrote: > > Hmm (untested, like above): > > > > class Synchronized: > >def __init__(self, generator): > > self.gen = generator > > self.lock = threading.Lock() > >def next(

Re: generators shared among threads

Paul Rubin wrote: > Hmm (untested, like above): > > class Synchronized: >def __init__(self, generator): > self.gen = generator > self.lock = threading.Lock() >def next(self): > self.lock.acquire() > try: > yield self.gen.next

Re: generators shared among threads

Paul Rubin wrote: > [EMAIL PROTECTED] writes: > > The main problem with this is that the yield leaves the lock locked. > > If any other thread wants to read the generator it will block. > > Ouch, good catch. Do you see a good fix other than try/finally? > Is there a c

Re: generators shared among threads

[EMAIL PROTECTED] writes: > The main problem with this is that the yield leaves the lock locked. > If any other thread wants to read the generator it will block. Ouch, good catch. Do you see a good fix other than try/finally? Is there a classical way to do it with coroutines and semaphores? --

Re: generators shared among threads

Paul wrote: >def f(): >lock = threading.Lock() >i = 0 >while True: >lock.acquire() >yield i >i += 1 >lock.release() > > but it's easy to make mistakes when implementing things like that > (I'm not even totally confident tha

Re: generators shared among threads

[EMAIL PROTECTED] (Alex Martelli) writes: > > g=itertools.count() > > I believe that in the current implementation you'd get "lucky", but > there is no guarantee that such luck would persist across even a minor > bugfix in the implementation. Don't do it. I remember being told that xrange(sys.ma

Re: generators shared among threads

Alex wrote: > Last, I'm not sure I'd think of this as a reentrantQueue, so > much as a ReentrantCounter;-). Of course! It must have been late when I named this class... I think I'll go change the name in my code right now. -- http://mail.python.org/mailman/listinfo/python-list

Re: generators shared among threads

<[EMAIL PROTECTED]> wrote: > Thanks for the great advice, Alex. Here is a subclass that seems to > work: You're welcome! > from Queue import Queue > from itertools import count > > class reentrantQueue(Queue): > def _init(self, maxsize): > self.maxsize = 0 > self.queue = []

Re: generators shared among threads

Thanks for the great advice, Alex. Here is a subclass that seems to work: from Queue import Queue from itertools import count class reentrantQueue(Queue): def _init(self, maxsize): self.maxsize = 0 self.queue = [] # so we don't have to override put() self.counter =

Re: generators shared among threads

[EMAIL PROTECTED] > def f() > i = 0 > while True: > yield i > i += 1 > g=f() > > If I pass g around to various threads and I want them to always be > yielded a unique value, will I have a race condition? Yes. Generators can be shared between threads, but they cannot be res

Re: generators shared among threads

<[EMAIL PROTECTED]> wrote: > hi, > > This seems like a difficult question to answer through testing, so I'm > hoping that someone will just know... Suppose I have the following > generator, g: > > def f() > i = 0 > while True: > yield i > i += 1 > g=f() > > If I pass g

Re: Generators vs. Functions?

On Sun, 05 Feb 2006 19:14:29 +1100, Steven D'Aprano <[EMAIL PROTECTED]> wrote: >On Sun, 05 Feb 2006 03:31:24 +, Neil Schemenauer wrote: > >> Peter Hansen <[EMAIL PROTECTED]> wrote: >>> More precisely, the state of the function is *saved* when a yield >>> occurs, so you certainly don't *recrea

Re: Generators vs. Functions?

Duncan Booth wrote: > Steven D'Aprano wrote: >>So on the basis of my tests, there is a small, but significant speed >>advantage to _calling_ a function versus _resuming_ a generator. > > I get the same, but the difference is much less on my system: With Python 2.4? Doesn't surprise me a bit. I t

Re: Generators vs. Functions?

On Sun, 05 Feb 2006 16:14:54 +, Neil Schemenauer wrote: > Steven D'Aprano <[EMAIL PROTECTED]> wrote: >> Have you actually measured this, or are you just making a wild >> guess? > > I haven't timed it until now but my guess it not so wild. I'm > pretty familiar with the generator implementati

Re: Generators vs. Functions?

Steven D'Aprano <[EMAIL PROTECTED]> wrote: > Have you actually measured this, or are you just making a wild > guess? I haven't timed it until now but my guess it not so wild. I'm pretty familiar with the generator implementation (having written the initial version of it). In Python 2.3, resuming

Re: Generators vs. Functions?

On Sun, 05 Feb 2006 09:49:21 +0100, Fredrik Lundh wrote: > Steven D'Aprano wrote: > >> So on the basis of my tests, there is a small, but significant speed >> advantage to _calling_ a function versus _resuming_ a generator. > > now add state handling to your micro-benchmark, and see if the funct

Re: Generators vs. Functions?

Steven D'Aprano wrote: t1.timeit() > 0.63980388641357422 ... t2.timeit() > 0.82081794738769531 > > So on the basis of my tests, there is a small, but significant speed > advantage to _calling_ a function versus _resuming_ a generator. I get the same, but the difference is much less on

Re: Generators vs. Functions?

Steven D'Aprano wrote: > So on the basis of my tests, there is a small, but significant speed > advantage to _calling_ a function versus _resuming_ a generator. now add state handling to your micro-benchmark, and see if the function example still runs faster. (hint: functions and generators do d

Re: Generators vs. Functions?

On Sun, 05 Feb 2006 03:31:24 +, Neil Schemenauer wrote: > Peter Hansen <[EMAIL PROTECTED]> wrote: >> More precisely, the state of the function is *saved* when a yield >> occurs, so you certainly don't *recreate* it from scratch, but merely >> restore the state, and this should definitely be

Re: Generators vs. Functions?

Peter Hansen <[EMAIL PROTECTED]> wrote: > More precisely, the state of the function is *saved* when a yield > occurs, so you certainly don't *recreate* it from scratch, but merely > restore the state, and this should definitely be faster than creating it > from scratch in the first place. Right

Re: Generators vs. Functions?

Joseph Garvin wrote: > Wolfgang Keller wrote: >>If this is actually also true in the general case, and not due to eventual >>non-representativeness of the test mentioned above, is it simply due to a >>less-than-optimum implementation of generators in the current Pyython >>interpreter and thus li

Re: Generators vs. Functions?

Joseph Garvin wrote: > > I am not a CPython or PyPy hacker, but I would guess that it will always > be slower as a matter of principal. When resuming a generator you have > to resetup the state the function was in when it was last called, which > I think should always be more costly than callin

Re: Generators vs. Functions?

Wolfgang Keller wrote: >If this is actually also true in the general case, and not due to eventual >non-representativeness of the test mentioned above, is it simply due to a >less-than-optimum implementation of generators in the current Pyython >interpreter and thus likely to change in the futu

Re: generators in Java?

On Fri, 30 Dec 2005, Tom Sheffler wrote: > Does Java have generators? I am aware of the "Iterator" interface, > but it seems much more restrictive. Python generators are useful > for many more things than simply list enumeration, but the Java > Iterator seems limited. What makes you think that

Re: generators in Java?

Tom Sheffler schrieb: > > This may have been discussed before, so I apologize. > > Does Java have generators? I am aware of the "Iterator" interface, > but it seems much more restrictive. Python generators are useful > for many more things than simply list enumeration, but the Java > Iterator s

Re: Generators and Decorators doing my head in ..

I usually point out my decorator module (http://www.phyast.pitt.edu/~micheles/python/decorator.zip) to simplify decorator usage. In this case you would use it as follows: from decorator import decorator @decorator # convert logFunctionCalls into a decorator def logFunctionCalls(function, *args, *

Re: Generators and Decorators doing my head in ..

Fantastic, thanks Leif and Paul, My problem is that i thought the decorator worked at the function runtime, not when the function gets created. -- http://mail.python.org/mailman/listinfo/python-list

  1   2   >