Why the exec?

    print "Hello world\n" * 100

That was the first thing that popped into my head upon reading the headline, though I abstracted it a bit:

  def print_many(n):
      print("hello, world\n" * n)

Though the `exec` option given above certainly is... interesting. :)

I think a better Python version would be

    print '\n'.join(['Hello world'] * 100)

No need for exec.

I wonder why 430gj9j added exec..

  print "Hello world\n"*100

Would have worked just fine.

He abstracted this loop:

    for i in xrange(100):
        statement

into:

   exec "statement" * 100

The 'no exec' alternatives propose something not as generic since they can only print something a number of times.

Or just

    print "Hello, World\n" * 100

No need for join either, and ends with a newline

that reminds me why I don't like Python. Ad-hoc tools (many) instead of a few general concepts working well together.

Btw at interview time this solution would not be acceptable, because you are using still a built-in language construct for looping.

You're right, Python isn't beautifully minimal. But the Scheme version is boring ;)

Rather than asking the interview candidate to use recursion for a problem that shouldn't be solved using recursion (unless in a language where recursion is the idiomatic iteration method), it would be better to ask about a problem that is best solved using recursion rather than printing "Hello world" -- perhaps something from Project Euler (http://projecteuler.net/).

On the contrary, wouldn't OP's solution be an example of more generalized implementation of multiplication? I can see that it is similar to (X * 2) where X defines behavior of __mul__.

Yes, there is chance that arbitrary objects can provide different semantics for __mul__. It would be true for any language.

Huh? This is a specific case of the * operator, which is overloaded for type string to return a repetition of the string. The only ad-hoc in the example is the print statement, which is gone in 3.2.

How do you know the __mul__ operator overload for string is implemented with iteration?

> This is a specific case of the * operator, which is overloaded

It is not operator overloading in the strictest sense, but more of duck typing. In Python (and Ruby), operators are syntactic sugar for method calls on the first operand.

Operator overloading on the contrary suggests a function add(a, b) that reacts differently through polymorphism (i.e according to the types of its arguments).

The distinction is important as overloading and polymorphism simply do not exist in Ruby and Python, only overriding.

My hope in using the phrase "operator overloading" was to bring to mind the familiar concept of operator ad-hoc polymorphism (which I would maintain duck typing is an example of) rather than to misleadingly describe the internals of the Python language. Nonetheless you are quite right on the details.

Well then you don't seem to know python and focus on some red herrings, because it's much more of the latter than the former. The example leverages general concepts such as duck typing and defining __mul__ for a string as doing something thoughtful.

> because you are using still a built-in language construct for looping.

That... makes no sense, the code is not looping anywhere.

And if you could somehow disqualify this bit, then recursion most definitely wouldn't qualify.

Or just this:

    print ('hello, world\n' * 100)[:-1]

Perl version:

perl -e 'print "Hello world\n" x 100;'