Skip to content

document/improve/remove the hidden "feature" that date vars have to end on "date" #68

@seb-wahl

Description

@seb-wahl

If you change (example)

test_initial_date: "3350-01-01"
ini_parent_date: "$(( ${test_initial_date} - ${echam.time_step}seconds ))"

to

test_initial_date2: "3350-01-01"
ini_parent_date: "$(( ${test_initial_date2} - ${echam.time_step}seconds ))"

in e.g. a runscripts, esm_runscripts will crash with

...
 File "/home/shkifmsw/.local/lib/python3.7/site-packages/esm_parser/esm_parser.py", line 1818, in find_variable
    var_result = do_math_in_entry(tree, var_result, full_config)
  File "/home/shkifmsw/.local/lib/python3.7/site-packages/esm_parser/esm_parser.py", line 2208, in do_math_in_entry
    result = eval(math)
  File "<string>", line 1
    3350-01-01 - 450seconds
          ^
SyntaxError: invalid token
glogin4:~/esm/esm_tools/runscripts/foci $

After narrowing done the problem to "I think the variable name must end on date, but why the hell, and where is that defined", I figured out that this is indeed the case:

def mark_dates(tree, rhs, config):
"""Adds the ``DATE_MARKER`` to any entry who's key ends with ``"date"``"""
if not tree[-1]:
tree = tree[:-1]
lhs = tree[-1]
entry = rhs
logging.debug(entry)
# if "${" in str(entry):
# return entry
if isinstance(lhs, str) and lhs.endswith("date"):
entry = str(entry) + DATE_MARKER
return entry

Is there a reasonable explanation for this? And if yes, we must document it and highlight it in blinking red in the documentation :-)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions