0
alpha = [0,1,2,3,4,5,6,7,8,9]

for a in alpha:
    for b in alpha:
        for c in alpha:
            for d in alpha:
                print str(a) + str(b) + str(c) + str(d)

The code above will generate all numbers between 0000 to 9999. However, I do not like the way the code is structured. Let's say I would want to do this to produce numbers up to a ten digit size; that would require 10 for loops. Is there another way the same result could be achieved, without having to insert countless of for loops?

Alexander Nilsson
  • 121
  • 1
  • 1
  • 5

3 Answers3

6

The obvious way:

for i in xrange(10000):        # or range if python 3
    print "{0:04d}".format(i)

You can also specify the with as an argument:

for i in xrange(10000):        # or range if python 3
    print "%0*d"%(4,i)
perreal
  • 94,503
  • 21
  • 155
  • 181
  • 1
    `"%0*d"%(4,4)` is neater I think ... but yeah – Joran Beasley Apr 25 '13 at 00:04
  • 1
    `xrange` is usually a whole lot more efficient than `range` in these situations. (See this SO question for why `xrange` should be used: [What is the difference between range and xrange?](http://stackoverflow.com/q/94935/836407) ). Other than that, great answer. – chown Apr 25 '13 at 00:04
  • For 10000, the efficiency difference is unlikely to make a difference. But yeah, for 10 digits, it definitely makes a difference… – abarnert Apr 25 '13 at 00:08
  • @JoranBeasley: I don't think we should be teaching novices almost-but-not-quite-deprecated `%`-formatting instead of modern `{}`-formatting. (Then again, I also don't think we should be teaching novices Python 2.x, and yet we clearly still are.) – abarnert Apr 25 '13 at 00:09
  • 1
    its not depreciated ... afaik they reversed that decision ... can you do that trick with the new format? (tbh I like % formating better it just looks more natural to me, I know that the new .format has many superior qualities, but % formatting just looks right to me) – Joran Beasley Apr 25 '13 at 00:12
  • @JoranBeasley: That's why I said "almost-but-not-quite-deprecated", because they decided not to deprecate it, and instead just put a bunch of comment all over the docs saying "You really should use the new-style formatting instead". There's no technical term for that status, but it puts it on par with things like, say, `os.system` or `popen`… – abarnert Apr 25 '13 at 00:41
  • @JoranBeasley: And you can't do _exactly_ the same trick, but only because you can do something much more flexible: nest arguments arbitrarily. For example, `'{1:0{0}d}'.format(4, i)`. Or, if you'd prefer to use names: `'{0:0{width}d}'.format(i, width=4)`. – abarnert Apr 25 '13 at 00:49
2

I'm not sure whether you want combinations_with_replacement or product. I think it's the latter, but… try them both with, say, 2 or 3, and see which one is what you're asking for.

for combination in itertools.combinations_with_replacement(alpha, 3):
    print ''.join(map(str, combination))

for element in itertools.product(alpha, repeat=3):
    print ''.join(map(str, element))

Although I'd probably generate the combinations out of strings, instead of generating them out of integers just to convert them to strings:

alpha = '0123456789'
for combination in itertools.combinations_with_replacement(alpha, 4):
    print ''.join(combination)
abarnert
  • 354,177
  • 51
  • 601
  • 671
  • 1
    Are you sure the OP wants c_w_r and not product? – DSM Apr 25 '13 at 00:02
  • @DSM: No, I'm not sure. Thanks. Rewrote the answer to show the OP how to figure it out for himself. – abarnert Apr 25 '13 at 00:06
  • The 'product' did the job. I only recently started using Python, so I had never heard of itertools. Thanks! – Alexander Nilsson Apr 25 '13 at 00:11
  • @JoranBeasley: Well, obviously this is better when you need the flexibility to do it with something other than the set of all decimal digits… but if you _don't_, it might just be an extra level of abstraction for no reason. – abarnert Apr 25 '13 at 00:11
0
expect_len = 10
max_val = 10**expected_len -1
my_list = ["%0*d"%(expect_len,val) for val in xrange(0,max_val+1)]

I think at least

Joran Beasley
  • 110,522
  • 12
  • 160
  • 179