On Tue, Jan 4, 2011 at 10:20 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Wed, Jan 5, 2011 at 1:58 AM, Guido van Rossum <guido@python.org> wrote:
> On Tue, Jan 4, 2011 at 2:49 AM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
>> I think someone else pointed this out, but replacing builtins externally to
>> a module is actually common for testing. In particular replacing the open
>> function, but also other builtins, is often done temporarily to replace it
>> with a mock. It seems like this optimisation would break those tests.
> Hm, I already suggested to make an exception for open, (and one should
> be added for __import__) but if this is done for other builtins that
> is indeed a problem. Can you point to example code doing this?

I've seen it done to write tests for simple CLI behaviour by mocking
input() and print() (replacing sys.stdin and sys.stdout instead is far
more common, but replacing the functions works too). If compile()
accepted a blacklist of builtins that it wasn't allowed to optimise,
then that should deal with the core of the problem as far as testing


Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

Ugh, I can't be the only one who finds these special cases to be a little nasty?

Special cases aren't special enough to break the rules.


"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you want" -- Me