Opposite of yield?
Peter Hansen
peter at engcorp.com
Wed Sep 10 17:41:32 EDT 2003
More information about the Python-list mailing list
Wed Sep 10 17:41:32 EDT 2003
- Previous message (by thread): Opposite of yield?
- Next message (by thread): Opposite of yield?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
achrist at easystreet.com wrote: > > Peter Hansen wrote: > > > > > > Queue.Queue.get() ... > > > > That looks good. But that needs a thread to block, right? Yep. > A generator manages to run without being a thread (at least > overtly). If we have the suck() statement, we also need > something that's the opposite of a generator (a Sucker?) > and something that's the opposite of an iterator (a Suckee?). > I'm starting to get an idea why this is completely not all > there. > > The main question this raises is "How lightweight are threads?" > Can I program with dozens or hundreds of python threads in a > program (for example under Windows) and not notice that this is > an inefficient or inept coding style? The real question might be why would you want to? If you don't want a thread, but you want something which takes input from elsewhere and does some processing, then returns control to some other place until more data is available (which is what one might assume if threads aren't good for you), there is already a convenient solution: the subroutine. ;-) Seriously, what's the requirement driving the need for this? (I suspect Erik Max's answer is still what you need, and you misunderstand the nature of what he was suggesting, but if you'll explain the specific case you have in mind we'll know for sure.) -Peter
- Previous message (by thread): Opposite of yield?
- Next message (by thread): Opposite of yield?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list