On Mon, Nov 9, 2015 at 11:26 AM, Ben Finney <ben+pyt...@benfinney.id.au> wrote: > Chris Angelico <ros...@gmail.com> writes: > >> Testing/mocking is a completely separate consideration (eg you can >> inject a shadow for a built-in name) > > Not for the purpose of making compiler optimisations, as BartC is > advocating. > > The compiler definitely should not treat “is this code part of a test > suite?” as a relevant criterion for deciding what optimisation. We > should certainly not have a compiler that makes needless difference to > code behaviour under test conditions versus non-test conditions. > > So, since those optimisations would cripple perfectly normal test code, > that should be sufficient to quash the desire to make them.
But I distinguish between crippling *performance* and crippling *functionality*. If the compiler optimizations are defeated, so the test suite falls back on the slow path, that means your tests run slower. Unless you're testing the optimizer itself, this shouldn't be a problem. This is broadly the same kinds of optimizations that Fat Python is playing with. Effectively, what it says is "I think that 'len' is this object", and then it guards the fast path with a quick check for validity. So if you go in and change something, the result is that the slow path gets used instead. The question then is whether it's worth the optimization effort. Will the slow path be penalized more than the fast path gains? Will the code complexity introduce more bugs? The same consideration comes up in JavaScript/ECMAScript (where object attributes can also be created dynamically), and I know some interpreters have been written to do a slot-based lookup, so the concept does have at least some merit. Personally, I'm dubious about the value of this in CPython; but I'm willing to be persuaded. ChrisA -- https://mail.python.org/mailman/listinfo/python-list