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

[Alex Martelli]

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.
> 
> So, I would be happy with the following:
> 
> 1. by default builtins cannot be changed, resulting in a performance
>    benefit;
> 
> 2. nevertheless, it is possible to use a command line switch to revert
>    to the current behavior.
> 
> If the project is to kill option 2, then I would be unhappy :-(

Sounds reasonable to me.  If nailing down built-ins is seen as good
_only_ for performance, then perhaps the same -O switch that already
exists could be used.  Personally, I think nailing down built-ins may
also be good for clarity in most cases, so I would prefer a more
explicit way to request [2].  However, we would then need a third
file-extension besides .pyc and .pyo -- clearly you would not want
the same bytecode for the "builtins nailed down" and "builtins can
be modified" modes; and that might pose some problems -- so perhaps
sticking to -O would be better overall.

I think that discussing the possibilities here is productive only up
to a point, so you might want to come to python-dev for the purpose,
at least when some clarification of possibilities has been reached.


Alex