RE: Controlling a generator the pythonic way

FWIW, PEP 342 is now titled "Coroutines via Enhanced Iterators" :) Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > I'm trying to figure out what is the most pythonic way to interact with a > generator. JFTR, so you don't think I'd suddenly lost interest: I won't be able to respond for a couple of days because I've just incurred a nice little hospital session... will be back next week. -

RE: Controlling a generator the pythonic way

Steve Holden wrote: > Sigh indeed. But if you allow next() calls to take arguments you are > effectively arguing for the introduction of full coroutines into the > language, and I suspect there would be pretty limited support for > that. You mean `PEP 342`_ which I posted earlier and is consider

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > Peter Hansen wrote: > > >>Thomas Lotze wrote: >> >>>I can see two possibilities to do this: either the current file position >>>has to be read from somewhere (say, a mutable object passed to the >>>generator) after each yield, [...] >> >>The third approach, which is certain

RE: Controlling a generator the pythonic way

Thomas Lotze wrote: > call. The picture might fit better (IMO) if it didn't look so much > like working around the fact that the next() call can't take > parameters for some technical reason. You might want to take a look at PEP 342 . Doesn't help you no

Re: Controlling a generator the pythonic way

"news:[EMAIL PROTECTED] > Thomas Lotze <[EMAIL PROTECTED]> writes: >> A related problem is skipping whitespace. Sometimes you don't care about >> whitespace tokens, sometimes you do. Using generators, you can either >> set >> a state variable, say on the object the generator is an attribute of, >

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > Mike Meyer wrote: > What worries me about the approach of changing state before making a > next() call instead of doing it at the same time by passing a parameter is > that the state change is meant to affect only a single call. The picture > might fit better (IMO) if it didn'

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > A related problem is skipping whitespace. Sometimes you don't care about > whitespace tokens, sometimes you do. Using generators, you can either set > a state variable, say on the object the generator is an attribute of, > before each call that requires a deviation from the d

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > Does anybody here have a third way of dealing with this? Sleeping a night sometimes is an insightful exercise *g* I realized that there is a reason why fiddling with the pointer from outside the generator defeats much of the purpose of using one. The implementation using a

Re: Controlling a generator the pythonic way

Peter Hansen wrote: > Fair enough, but who cares what the generator code thinks? It's what the > programmer has to deal with that matters, and an object is going to have a > cleaner interface than a generator-plus-mutable-object. That's right, and among the choices discussed, the object is the o

Re: Controlling a generator the pythonic way

Mike Meyer wrote: > Yes, such a switch gets the desired behavior as a side effect. Then again, > a generator that returns tokens has a desired behavior (advancing to the > next token) as a side effect(*). That's certainly true. > If you think about these things as the > state of the object, rath

Re: Controlling a generator the pythonic way

Thomas Lotze <[EMAIL PROTECTED]> writes: > A related problem is skipping whitespace. Sometimes you don't care about > whitespace tokens, sometimes you do. Using generators, you can either set > a state variable, say on the object the generator is an attribute of, > before each call that requires a

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > Which is, as far as the generator code is concerned, basically the same as > passing a mutable object to a (possibly standalone) generator. The object > will likely be called self, and the value is stored in an attribute of it. Fair enough, but who cares what the generator co

Re: Controlling a generator the pythonic way

Peter Hansen wrote: > Thomas Lotze wrote: >> I can see two possibilities to do this: either the current file position >> has to be read from somewhere (say, a mutable object passed to the >> generator) after each yield, [...] > > The third approach, which is certain to be cleanest for this situat

Re: Controlling a generator the pythonic way

Thomas Lotze wrote: > I can see two possibilities to do this: either the current file position > has to be read from somewhere (say, a mutable object passed to the > generator) after each yield, or a new generator needs to be instantiated > every time the tokenizer is pointed to a new file position