[Python-Dev] Re: More int/long integration issues

[Guido van Rossum]

> > and that there's no definition of range other than the built-in one
> > (this requires a subtle change of language rules); it can then
> > substitute an internal equivalent to xrange().
> 
> That sounds good. What sort of subtle language change
> do you have in mind which would permit this deduction?

An official prohibition on inserting names in other namespaces that
shadow built-ins.  The prohibition needn't be enforced (although that
would be nice).  A program that does

  import foomod
  foomod.range = ...

would be invalid, but an implementation might not be able to catch all
cases, e.g.

  import foomod
  foomod.__dict__['range'] = ...

It could be enforced, mostly, by making a module's __dict__ attribute
return a read-only proxy like a new-style class's __dict__ attribute
does, and putting an explicit ban on setting certain names in the
module setattr implementation.  But the module itself could also play
games, e.g. it could do

  exec "range = ..." in globals()

Another module could also do

  from foomod import f # a function
  f.func_globals['range'] = ...

All these things would be illegal without necessarily being enforced.
(The only way I see for total enforcement would be to change the dict
implementation to trap certain assignments.)

BTW,

  import foomod
  foomod.foo = ...

would still be allowed -- it's only setting previously unset built-in
names (or maybe built-in names that are known to be used by the
module) that would be prohibited.

Also, foomod could explicit allow setting an attribute by doing
something like

  range = range # copy the built-in into a global

to disable the optimization.  I.e. setting something that's already
set should always be allowed.

--Guido van Rossum (home page: http://www.python.org/~guido/)