Question about math.pi is mutable

[BartC]

On 08/11/2015 11:30, Steven D'Aprano wrote:
> On Sun, 8 Nov 2015 09:40 pm, Bartc wrote:

>> This is what I mean about people not understanding it!
>
> I'm pretty sure I understand what *I* mean by constant, and what Pascal
> means by it, and why the Pascal meaning doesn't quite match what Python can
> do. I'm not sure I understand what *you* mean, or why you think a "variable
> that won't change" isn't good enough.

I showed you what I mean. A named constant is a just a value - with a 
label. That value doesn't need to be stored in a 'box' anywhere, in 
exactly the same manner as values that can be written to (and therefore 
at risk of being overwritten).

But let me turn it around: why is it so important to use variables for 
this purpose?

>> In NASM terms, a named constant is like:
>>
>>       daysinweek   equ   7           ; definition
>>
>>       mov rax, daysinweek            ; using it, as immediate value
>>       mov rbx, daysinweek*2          ; an a 'compile-term' expression
>> ;   mov daysinweek,8               ; can't be done! Illegal syntax
>
> In pseudo-Python, we have:
>
> const daysinweek = 7  # let's just pretend it exists
> x = daysinweek + 1  # this is fine
> daysinweek = 8  # an error
>
> Apart from the difference between compile-time and run-time, why would this
> not be satisfactory?

If that's all that's possible, that it will have to do. And might solve 
the OP's problem.

But for a true named constant, there is no actual assignment. It really 
is not necessary. 'daysinweek' is just a synonym for '7'.

>
>> While a 'const' variable, C style, might be:
> [...]
>
> Why does your C code look like assembler?

I mean the 'const' is C style. The assembly code is to highlight the 
difference between what C calls a const, and what I call a named constant.

> I am not interested in the limitations of low-level machine languages. They
> have very little to say about what Python can or should do.

OK, let's take a higher level one:

  const a = 2
  var   b = 3

  c = a+b

which might generate a byte-code like this:

       push_ci   2
       push_m    [b]
       add
       pop_m     [c]

Now apply this to Python byte-code. Can you not see the advantage of not 
having to deal with variable names, reference counts, garbage collection 
and all that?

I don't know what you had in mind for implementing the pretend 'const' 
in your Python example above. But if it takes the form of an extra 
runtime attribute, then all variable accesses will be slowed then if it 
is has to be checked for every assignment, and 'const' names won't be 
any faster.

>> In the language however, you will not be able to use the named constant
>> as an lvalue, and you will usually be able to use it for compile-time
>> constant folding and for dimensioning fixed-bound arrays and such.)
>
> We're talking about Python, and how the concept of "const" might apply to a
> Python-like language. Compile-time constant folding is not part of it,
> because the constant itself might not exist at compile-time:
>
> const START = time.time()

You're thinking in C terms again. The C 'const' really means 'read-only' 
and applies to ordinary variables. It has nothing to do with my named 
constants which are always known at compile-time

(That's if the definitions are visible. If not, then they will be known 
at the time the module they're in is compiled. Linking these is one of 
the problems in a Python implementation.)

> Fixed-bound arrays are irrelevant (neither lists nor arrays are
> fixed-bounds; tuples are, but they are constructed at runtime, not compile
> time).

Think of a possible 'switch' statement then, and the values for its case 
labels.

> Python has such a "more elaborate way" of executing source code:
>
>
> exec("""
> if condition:
>      import time
>      const START = time.time()
>      x = START + 1
> """)

(1) That is not a const but a variable with a read-only attribute. The 
expression after the "=" should itself be a constant expression or a 
literal value. (No reason why Python shouldn't have such an attribute, 
but that's different from what I'm talking about.)

(2) I assume that the contents of the string passed to exec() are first 
compiled to byte-code. Then that's the same as a normal compile, with 
the same problems of visibility and imparting its constant definitions 
to code that is compiled separately. (If the use 'exec' is more subtle, 
then we might as well give up!)

-- 
BartC