Question about math.pi is mutable

[Ben Finney]

Chris Angelico <rosuav at gmail.com> writes:

> 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. […] 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.

You misunderstand me. I'm not saying the optimisations would be
crippled. I am saying that, in order to achieve those optimisations, the
*test code* would be crippled.

I am pointing out that the assumption necessary for the optimisation
BartC is advocating – the optimisation of module attributes to be
immutable after compilation – depends on crippling the *functionality*
needed for many uses, including test code uses.

Since the compiler should not be in the position of deciding whether
code is test code or not, it cannot use that criterion to decide whether
to enable or disable the optimisation.

So either the optimisation should never be enabled (my perference), or
test code will unwittingly be crippled by the assumptions needed for
that optimisation.

-- 
 \     “We are all agreed that your theory is crazy. The question that |
  `\      divides us is whether it is crazy enough to have a chance of |
_o__)            being correct.” —Niels Bohr (to Wolfgang Pauli), 1958 |
Ben Finney