object.enable() anti-pattern
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Thu May 9 01:37:35 EDT 2013
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
More information about the Python-list
mailing list