Tinkering with builtins (was: Re: True, False, None)

[Peter Hansen]

Michele Simionato wrote:
> 
> "John Roth" <newsgroups at jhrothjr.com> wrote in message news:
> > There's a movement
> > to make just about everything in the built-in scope immutable and
> > not rebindable at any lower scope for performance reasons.
> 
> I am a bit worried by this movement. While I have found no reason to twick
> the builtins in production code, I have found specific situations where
> the ability of tinkering with the builtins is extremely convenient.
> Typically this happens in the debugging phase. For instance I have used
> tricks such as modifying the `object` class to induce tracing capabilities
> on all my classes, withouth touching my source code.

Another use case I've raised in the past, and I believe it is accepted
that it is a valid one, is in automated unit testing or acceptance testing
where it is often extremely beneficial to be able to "mock" a builtin by
replacing it with a custom test method.

For us, the most common use of this is to change open() to return a
special mock file object which doesn't actually cause any disk access.

Removing the ability to do this would cripple our ability to properly
test some code.

Alex' suggestion of using -O to switch to a mode where builtins are
static is okay as far as it goes, but it would prevent proper testing
of code that relies on the aforementioned technique when one wishes
to verify that the standard -O improvements still work.  I'd vote for
decoupling this behaviour from the rest of -O, as Michele suggests.

-Peter