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
--
https://mail.python.org/mailman/listinfo/python-list
