[Python-ideas] 'const' statement
Cameron Simpson
cs at zip.com.au
Fri Jan 18 05:28:53 CET 2013
On 18Jan2013 14:37, Ben Finney <ben+python at benfinney.id.au> wrote:
| "Harding, James"
| <james.d.harding at 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 at zip.com.au>
More information about the Python-ideas
mailing list