generator expressions: performance anomaly?

Ola Natvig ola.natvig at infosense.no
Tue Jan 18 09:01:42 EST 2005


Diez B. Roggisch wrote:
>>Would it be a bad solution to make that a list or tuple of ten
>>time.time() calls, you could also restrict what theese prebuilding
>>sequenses could contain, or perhaps try to prebuild them, and then fail
>>if it's impossible.
> 
> 
> I don't fully understand what you mean. Restricting them would mean to add
> static declarations that say "I return the same whenever you call me" -
> which is even more than the already fragile "const"  declaration of c++
> allows. 
> 
> And for your second suggestion - how exactly do you check for failing?
> Generating 2 elements and checking if they are equal to the first two of
> the old list? What about overloaded __cmp__/__eq__, or just the last
> element differing?
> 
> This problem is too complex to solve automatically - domain knowledge is
> needed. As the code Antoon presented also suggests the simple solution:
> 
> 
> lst = list(time.time() for i in xrange(10))
> tpl = tuple(lst)
> 
> 
> I don't see why this is a desirable feature at all. Keep in mind that
> putting statements or even stackframes between those two statements above
> utterly complicates things. And we even didn't dig into the dynamic
> features of python that for example make it possible to alter time.time
> like this
> 
> time.time = random.random()
> 
> so that it behaves totally different - while the syntactically equivalence
> still holds. No chance of catching that. 

My thoughts where to let the 'leftmost' section of the expression to be 
intact so that any of the dynamic things done to this part, i.e. 
replacing time.time with random.random are taken into consideration. 
What can be done is to extract the expression into a loopless structure

lst = list(time.time() for i in xrange(10))
would be compiled to the bytecode version of:
lst = [time.time(), time.time(), time.time(), time.time() ...]

Then time.time can do whatever it wants to. It's the (x)range function 
that we need to enshure returns the same values in every execution. This 
*IS* a useless feature, but I think it's possible to make it work.

ola



More information about the Python-list mailing list