Shadowing builtins (was Re: a pyrex-inspired for-i-from-1-to-n ...)

[Tim Hochberg]

Peter Hansen wrote:
> Jp Calderone wrote:
> 
>>  Now, in its current state, it is impossible for the Python interpreter to
>>know this.  What if range() is rebound?  So this can't be done now.  But, if
>>some of the talk about forbidding the shadowing of builtins bears fruit, it
>>might someday be possible for CPython to make this optimization, and all
>>without any ugly syntax hacks.
> 
> 
> Ouch!  *Forbidding* it?!  That would cripple some of my most sophisticated
> and effective unit and acceptance tests!  I dearly hope that "forbid" was
> an overly strong choice of verb.

I believe what was discussed was making shadowing of builtins from 
outside of a module forbidden. So:

    range = my_custom_range_function

would be OK. While,

    some_random_module.range = my_custom_range_function

would not.

> What would be wrong with "discouraging", or "making it clear to the 
> compiler when it happens" or something?

I think that was more or less the idea of forbidding rebinding the 
module -- the compiler can't find the rebinding when it occurs from 
outside of a module.

> Where is this discussion going on, and can I/need I participate to put
> forth my perspective on this.  

The discussion was going on on python-dev last month. It seemed to have 
died down last I lurked.

> I'm coming to *count* on this as one of
> the most effective solutions for certain kinds of testing.  (Specifically,
> by creating a mock file system by intercepting open() calls in my own
> method, to allow generating of various file system errors and situations
> and to increase performance of unit tests by avoiding the real file
> system.)
> 
> -Peter


-tim