Question about math.pi is mutable

[Steven D'Aprano]

On Sun, 8 Nov 2015 09:40 pm, Bartc wrote:

> On 08/11/2015 02:59, Steven D'Aprano wrote:
>> On Sun, 8 Nov 2015 02:01 am, Bartc wrote:
>>
>>> Neither have the simplicity of concept of Pascal's 'const', which is
>>> just a named value. Not a variable that won't change once initialised,
>>> not a parameter that won't be changed nor any addressable location.)
>>
>> Unfortunately the concept of "named value" doesn't match well with
>> Python's design. That implies a separate compilation step which doesn't
>> fit well with Python's runtime semantics. Very little happens at
>> compile-time in Python that *must* happen at compile-time.
>>
>> I'm also not sure what difference you think there is between "named
>> value" and "variable that won't change once initialised".
> 
> 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.


> 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?

Oh, and just to satisfy Ben, the determined monkey-patcher can write:

globals()['daysinweek'] = 8

if they really want to defeat the compiler. The idea is to avoid
*accidental* bindings.



> While a 'const' variable, C style, might be:
[...]

Why does your C code look like assembler?


> So in native code, a named value is not much different to a literal such
> as 7, or 3.14159. (But unlike C's #define, the name is a proper symbol
> with normal scope rules, and a type).
> 
> The distinction at the machine level can be blurred with some
> instructions sets where there might not be an immediate data option for
> some data widths or types. Also where named constants are applied to
> things such as strings, which necessarily use storage.

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.


> 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()

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


>> Python has a convention for "constants" -- all UPPERCASE names. The fact
>> that the convention exists is enough to prove that the concept
>> of "constant" is a useful one. The difference between Python's
>> pseudo-constants and (say) Pascal's actual constants is that in Python,
>> the burden of ensuring that neither you, nor any of the libraries you
>> call, modifies the "constant" falls on you, the user, whereas in Pascal
>> the compiler or interpreter performs that checking for you.
> 
> With a real named constant the check can always be done at compile-time.
> Unless you have a pure interpreter or some more elaborate way of
> executing source code.

Python has such a "more elaborate way" of executing source code:


exec("""
if condition:
    import time
    const START = time.time()
    x = START + 1
""")




-- 
Steven