[Python-ideas] 'const' and 'require' statements

Harding, James james.d.harding at siemens.com
Fri Jan 18 02:52:28 CET 2013


Hello,

I am new here but am itching with an idea. Here are two separate ideas but they are related so they shall both be presented at the same time.

The first idea is for a 'const' statement for declaring constant names. 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)

Constant names would be limited in scope. A constant defined in a function would only have a life to the end of the function, for instance.

Now why should there be such a syntax if the existing language already has a mechanism for effectively declaring constants, which it does? First, it opens possibilities for the compiler to do things like more constant folding and generally producing more efficient code. Second, since the compiler substitutes for the name at compile time, there is no chance for the name to be stepped on at run-time. Third, ideas such as PEP 3103 could be re-visited. One of the problems in PEP 3103 was that so often constants are represented by names and those names may be changed and/or the constant values in those names are not known until run-time.

Constant names are fine but of limited use if they may only be used within the module they are declared in. This brings up the second idea of a 'require' statement.

The import statement of Python is executed at run-time. This creates a disconnect between modules at compile time (which is a good thing) but gives the compiler no hint as to how to produce better code. What I propose is a 'require' statement with almost exactly the same syntax as the import and from statements but with the keyword 'require' substituted for 'module'. The word require was chosen because the require declaration from the BLISS language helped inspire this idea. C minded people might prefer using a word such as include be used instead.

What the require statement would do is cause the module to be read in by the compiler and compiled when the statement is parsed. The contents of a required module could be restricted to only be const statements in order to avoid the many headaches this would produce. Examples:

    require font_data
    from stat_constants require ST_MODE
    from weekdays require *

In the first example, the name 'font_data' would be a constant module to the compiler. An expression such as font_data.FontName would at compile-time reference the constant name FontName from the font_data module and substitute for it. In the second example, the constant name ST_MODE is added to the current scope. In the third example, all constant names defined in the module (except those with a '_' prefix) are added to the current scope. Since the names added are constant names and not variable names, it is OK to use require * at the function scope level.

In order to help compatibility with existing uses and to avoid declaring constants twice, a require statement could use a 'as *' to both include constant names and assign them to a module's dictionary. For example, the file stat.py might do something like:

    require stat_constants as *

This would add all the constant names defined in the stat_constants module and place them in the stat module's dictionary. For instance, if there is the line in stat_constant.py:

    const ST_MODE = 0

Then for stat.py the compiler will act as if it saw:

    ST_MODE = 0

Well, those are my two bits of ideas.

Thank you,

James Harding
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130118/7ec53746/attachment.html>


More information about the Python-ideas mailing list