[Python-ideas] Optimizing builtins

[spir]

On Sat, 01 Jan 2011 12:52:54 +1100
Steven D'Aprano <steve at pearwood.info> wrote:

> > Now, *in practice* such manipulations are rare (with the possible
> > exception of people replacing open() with something providing hooks
> > for e.g. a virtual filesystem) and there is probably some benefit to
> > be had. (I expect that the biggest benefit might well be from
> > replacing len() with an opcode.) I have in the past proposed to change
> > the official semantics of the language subtly to allow such
> > optimizations (i.e. recognizing builtins and replacing them with
> > dedicated opcodes). There should also be a simple way to disable them,
> > e.g. by setting "len = len" at the top of a module, one would be
> > signalling that len() is not to be replaced by an opcode. But it
> > remains messy and nobody has really gotten very far with implementing
> > this. It is certainly not "low-hanging fruit" to do it properly.  
> 
> Here's another thought... suppose (say) "builtin" became a reserved 
> word. builtin.range (for example) would always refer to the built-in 
> range, and could be optimized by the compiler. It wouldn't do much for 
> the general case of wanting to optimize non-built-in globals, but this 
> could be optimized safely:
> 
> def f():
>      for i in builtin.range(10): builtin.print(i)
> 
> while this would keep the current semantics:
> 
> def f():
>      for i in range(10): print(i)

I had a similar question in a different context (non-python). The point was to prevent core semantic changes in a "pedagogic" mode, such as the sense of an operator on a builtin type. Eg have Real.sum 'untouchable' so that 1.1+2.2 returns what is expected.
Instead of protected kywords, my thought went toward read-only (immutable?) containers, where 'container' is a very lose notion including types and scopes that hold them (and even individual objects that can be generated without type).


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com