Corbin’s solutions look interesting.

Iterators and generators (and generator expressions, which exist since a somewhat recent Python version) are pretty powerful. A pretty good resource for the first two at least, is the chapter about them in the Python Cookbook, 2nd edition – the chapter is by Raymond Hettinger, a Python core developer, who is the main designer of those two language features, IIRC. I have the book and read that chapter a while ago. Still have to get my head around some of the capabilities of those two features – some of them are a little mind-twisting – but very useful, including for things like efficiency / performance. An example that comes to mind, off the top of my head, from that chapter, is one that uses either or both of iterators and generators to implement an efficient yet memory-saving fetch routine for an unknown (and potentially very large) number of records from a database cursor in a client-server environment (Python client, DB server). The problem is that if you use the Python DBI method fetchone(), you’re not making full / efficient use of the capabilities of the database driver and the network, particularly if the table is a lookup table with a small record size, since in that case many records may fit into even a single network packet, while if you use fetchall(), you may overflow your client memory. So he implements a fetchmany() that avoids both issues, with a user-settable number of records to fetch in each call to the iterator – same number in each call, though – you set the number while creating the iterator, IIRC. Then, by tweaking that number over multiple runs, I guess you could find an optimal number for your particular hardware / software / network environment. Neat idea.

And speaking of the Python Cookbook, I heard somewhere that the 3rd edition is in the pipeline. Looking forward to it …

For (3), any() is a far more elegant solution:

Another approach to (10) is to use some itertools:

I answered all of them here: http://news.ycombinator.com/item?id=2610879

range([start], stop[, step])¶

This is a versatile function to create lists containing arithmetic progressions

I later recollected range returns a list whereas it is xrange which returns a generator (or somthing rather similar in terms of a memory optimised way).

Thanks.

list(range(1,1001))

is redundant, because range() itself returns a list:

>>>print type(range(1, 1001))