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/)