I don't think you can call these antipatterns. It's just a classic example of writing one language in another language. Ironically though, the author happens to use a closure in the examples 3C and 3D. Har har.
While closures and objects have something in common (both can, for example, store state) they're of quite different mindsets. And you can't easily mix mindsets because such mindsets are the terms in which the programmer thinks in. Try writing a program both in Java-mindset and in Haskell-mindset in the same source file of Java, Haskell, or C.
There's code where using objects instead of closures would look abhorring and there's code where using closures would look totally out of the place. There's also a related koan that was just referred on HN a few days ago.
Python seems to be the best argument against misunderstood pseudo-OO since C++ and Java.
"While 3A is shorter, I think it is much less clear then 3B, 3C or 3D, the class examples. I think of a closure in terms of an outer function that needs to operate on an inner function, such as in the case of a decorator. Using a closure just to delay execution of a function doesn't seem right to me, and I feel like it obscures the code. "
Well, this exemplifies everything that is wrong with Python and its community. I have long since decided that Python is not for intellectually honest people, and every blog post about it I stumble upon just reinforces that observation.
While closures and objects have something in common (both can, for example, store state) they're of quite different mindsets. And you can't easily mix mindsets because such mindsets are the terms in which the programmer thinks in. Try writing a program both in Java-mindset and in Haskell-mindset in the same source file of Java, Haskell, or C.
There's code where using objects instead of closures would look abhorring and there's code where using closures would look totally out of the place. There's also a related koan that was just referred on HN a few days ago.