[Python-Dev] Re: More int/long integration issues
Guido van Rossum
Thu, 13 Mar 2003 19:22:09 -0500
> > 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
foomod.range = ...
would be invalid, but an implementation might not be able to catch all
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.)
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
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/)