Steven D'Aprano <[EMAIL PROTECTED]> wrote: ... > > s = [k for k in iterable] > > > > if I know beforehand how many items iterable would possibly yield, would > > a construct like this be faster and "use" less memory? > > > > s = [0] * len(iterable) > > for i in xrange(len(iterable)): > > s[i] = iterable.next() > > Faster? Maybe. Only testing can tell -- but I doubt it. But as for less
Testing, of course, is trivially easy: Helen:/tmp alex$ python -mtimeit -s'i=xrange(7)' 'L=[x for x in i]' 100000 loops, best of 3: 6.65 usec per loop Helen:/tmp alex$ python -mtimeit -s'i=xrange(7)' 'L=list(i)' 100000 loops, best of 3: 5.26 usec per loop So, using list() instead of that silly list comprehension does have an easily measurable advantage. To check the complicated option...: Helen:/tmp alex$ python -mtimeit -s'i=xrange(7)' ' s = [0]*7 u = iter(i) for x in xrange(7): s[x] = u.next() ' 10000 loops, best of 3: 24.7 usec per loop So, the "advantage" of all the complications is to slow down execution by about four times -- net of all the juicy possibilities for confusion and errors (there is no common Python type on which you can both call len(...) AND the .next() method, for example -- a combination which really makes no sense). *SIMPLICITY* is the keyword here -- list(...) is by far simplest, and almost five times faster than that baroque gyrations above... Alex -- http://mail.python.org/mailman/listinfo/python-list
