Seebs wrote: > On 2011-08-17, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> > wrote:
>> Fortunately, while we are proud of having that ability, actually *using* >> it is considered a mortal sin. We're not Ruby developers -- if you >> actually monkey-patch something, especially built-ins, you can expect to >> be taken outside and slapped around with a fish if you get caught. > > Okay, so. > > Here's what I don't get. > > If it's such a bad thing, *why is it allowed*? Why are you proud of the > ability to do something that you are never socially-allowed to do? Why does any language allow monkey-patching? Because: (1) it is a consequence of a clean language design that doesn't special case things unless absolutely necessary -- monkey-patching wasn't added to the language, it just emerged given the basic language design; (2) consequently it isn't some special technique, it is just a special name given to ordinary, humdrum, everyday things like name-binding within a namespace; (3) and yet it is a powerful and useful ability that lets you extend both the language and libraries (yours or third party) while still writing very clean code; (4) it's also pretty cool that you can do these things; and most importantly (5) all of the above. Even if we shouldn't (ab)use it in production, it is still greatly useful for quick and dirty scripts, testing, experimentation and debugging. And sometimes monkey-patches end up in production. For example, the standard library site.py file adds help() and quit() commands to builtins at startup. Or you might grab an instance of some third-party class, and dynamically adding a method or an attribute to it. Why bother sub-classing it? There's a scene in James Clavell's "Shogun" which is relevant. Toranaga, the Japanese warlord, discovers that the Englishman John Blackthorne has betrayed his rightful ruler. Blackthorne protests that there are mitigating circumstances. Toranaga says that there can never be any mitigating circumstances for disloyalty to one's liege-lord. Blackthorne replies that there is one: if you win. The same applies for monkey-patching and other dangerous techniques. There can be no excuse for doing something like that in production... unless it is better than the alternatives. [...] > It sounds to me like Python is very proud of having a feature which no > one would ever use. ... Why? Don't get me wrong, there are plenty of people who would give up Python's extreme dynamicism is a heartbeat, if it were up to them. It does play havoc with the ability to optimise Python code, and is one of the reasons why CPython isn't as fast as (say) Lua. But the PyPy people are well on the way to blunting that criticism, with a fast, effective JIT optimising compiler that will be fast in the common case and no worse off in the rare times that built-in functions have been shadowed or modified. (PyPy is already about twice as fast as CPython, and in a few carefully crafted examples faster than C code.) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
