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