On 18Jan2013 14:37, Ben Finney <ben+python@benfinney.id.au> wrote: | "Harding, James" | <james.d.harding@siemens.com> writes: | > Its syntax would be: | > 'const' identifier '=' expression | > | > The expression would be restricted to result in an immutable object | > such as 17, "green", or (1,2,3). The compiler would effectively replace | > any use of the identifier with this expression when seen. Some examples | > of constants might include: | > | > const ST_MODE = 0 | > const FontName = "Ariel" | > const Monday = 1 | > const Tuesday = Monday + 1 # may use previously defined const | > in expression. Compiler will fold constants (hopefully) | | So, the compiler will “replace any use of the identifier with” the | constant value. | | const ST_MODE = 0 | const ST_FILENAME = "foo" | const ST_RECURSIVE = True | | name_prefix = "ST_" | foo = globals().get(name_prefix + "MODE") | bar = globals().get(name_prefix + "FILENAME") | baz = globals().get(name_prefix + "RECURSIVE") | | What do you expect the compiler to do in the above code? Personally I'd expect the compiler to produce essentially the same code it does now with stock Python. After all, name_prefix isn't a const. But under his proposal I'd expect the compiler to be _able_ to produce inlined constant results for bare, direct uses of ST_MODE etc. If I'd written his proposal I'd have probably termed these things "bind-once", generating names that may not be rebound. They would still need to be carefully placed if the compiler were to have the option of constant folding i.e. they're need to be outside function and class definitions, determinable from static analysis. Just comments, not endorsement:-) -- Cameron Simpson <cs@zip.com.au>