On Thu, 09 May 2013 02:38:36 +0000, Dan Sommers wrote: > Think of spinning off a thread: initialize it synchronously, and then > let it execute asynchronously. We tend towards that pattern even when > we know that execution will be synchronous, because we also that it > could be asynchronous one day.
Whether it is synchronous or asynchronous is irrelevant. I can see use-cases for separating "make it go" from initialisation. It all depends on what you might want to do to the object before making it go. If the answer is "Nothing", then there is no reason not to have the constructor make it go. If the answer is, "Well, sometimes we need to do things to the object before making it go", then it makes sense to separate the two: blob = MyBlob(arg1, arg2, agr3) blob.poke("with a stick") blob.append(data) blob.foo = "spam" blob.make_it_go() I'm not talking about this case. I'm talking about the case where there's nothing you can do with the blob before making it go. > Yes, we could wrap that up in a neat > bundle, but explicit is better than implicit. "And that is why we always write code like this: n = int(int(len(something)) + int(1)) just to be sure that the result is explicitly an int and not just implicitly an int. Suppose some Javascript programmer was reading the code, and they thought that 1 was a floating point value. That would be bad!" -- Steven -- http://mail.python.org/mailman/listinfo/python-list