Question about math.pi is mutable

[Chris Angelico]

On Mon, Nov 9, 2015 at 11:26 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
> Chris Angelico <rosuav at 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