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/ -- http://mail.python.org/mailman/listinfo/python-list
