Controlling a generator the pythonic way

[Steve Holden]

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 this situation, is
>>to have a custom class which stores the state information you need, and
>>have the generator simply be a method in that class.
> 
> 
> 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.
> 
> Probably this is indeed the best way as it doesn't require the programmer
> to remember any side-effects.
> 
> It does, however, require a lot of attribute access, which does cost some
> cycles.
> 
Hmm, you could probably make your program run even quicker if you took 
out all the code :-)

Don't assume that there will be a perceptible impact on performance 
until you have written it they easy way. I'll leave you to Google for 
quotes from Donald Knuth about premature optimization.

> 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 default, or you can
> have a second generator for filtering the output of the first. Again, both
> solutions are ugly (the second more so than the first). One uses
> side-effects instead of passing parameters, which is what one really
> wants, while the other is dumb and slow (filtering can be done without
> taking a second look at things).
> 
And, again, your obsession with performance obscure the far more 
important issue: which solution is easiest to write and maintain. If the 
user then turns up short of cycles they can always elect to migrate to a 
faster computer: this will almost inevitably be cheaper than paying you 
to speed the program up.

> All of this makes me wonder whether more elaborate generator semantics
> (maybe even allowing for passing arguments in the next() call) would not
> be useful. And yes, I have read the recent postings on PEP 343 - sigh.
> 
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.

regards
  Steve
-- 
Steve Holden        +1 703 861 4237  +1 800 494 3119
Holden Web LLC             http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/