Overview

Replaces eval() with ast.literal_eval() in the Freyja module when parsing the summarized line from demix output files (e.g. [('BQ.1*', 0.983), ('Omicron', 0.011)]). Also expands the exception handler to include SyntaxError.

Code Quality & Best Practices

• Correct replacement: ast.literal_eval() is the standard, idiomatic Python replacement for eval() when only Python literals (strings, numbers, tuples, lists, dicts, sets, booleans, None) need to be parsed. It correctly handles the expected Freyja data format.
• Exception handling expanded correctly: literal_eval() raises SyntaxError on malformed input (whereas eval() would raise various other exceptions). Adding SyntaxError alongside ValueError is the right call — this would have been a silent regression if omitted.
• Import placement: from ast import literal_eval is correctly placed with the standard-library imports at the top of the file.
• Minimal diff: The change is tightly scoped with no unrelated modifications.

Security

This is the primary motivation for the PR and it's handled correctly:

• eval() can execute arbitrary Python code. If an attacker could control the contents of a Freyja output file (e.g. via a compromised pipeline or untrusted input directory), they could achieve code execution.
• ast.literal_eval() refuses to evaluate anything that isn't a Python literal, eliminating that vector entirely.

Potential Issues / Minor Notes

• Data format assumption: The in-code comment shows ('key', value) with an unquoted value. If Freyja ever emits a non-literal token there, literal_eval() will raise SyntaxError — which is now caught and logged. This is actually safer than before, where eval() might have silently evaluated something unexpected. No action needed.
• write_data_file ordering (pre-existing, not this PR): At line 69, write_data_file is called before the data_by_sample dict is sorted at line 72. This means the written file has non-deterministic key order while the in-memory dict used for plots is sorted. Low impact but worth a follow-up.
• Note: The commit fee051ef ("Use safe alternative to eval()") already appears at the tip of main. It's worth confirming this PR hasn't been accidentally applied twice or that the branch is up to date before merging.

Test Coverage

No new tests are added. Given the nature of the change (a drop-in safer replacement), a unit test covering:

1. Valid input parses correctly.
2. Malformed input (e.g. [('key', __import__('os'))]) is caught and logged rather than executed.

...would strengthen confidence, but is not strictly required for a change this mechanical.

Summary

Looks good to merge. The one thing to double-check is whether fee051ef already contains this change on main.