Why no warnings when re-assigning builtin names?

[Steven D'Aprano]

Seebs wrote:

> On 2011-08-17, Steven D'Aprano <steve+comp.lang.python at 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