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 to be cleanest for
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 considered
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.
--
FWIW, PEP 342 is now titled Coroutines via Enhanced Iterators :)
Tim Delaney
--
http://mail.python.org/mailman/listinfo/python-list
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
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
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't
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,
before each
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
http://www.python.org/peps/pep-0342.html. Doesn't help you now,
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.
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 situation, is
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 code
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
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, rather
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 one
15 matches
Mail list logo
