Skip to content

Core: replace the eval in OptionsCreator.py #5828

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Berserker66 merged 1 commit into from
Jan 15, 2026
Merged

Core: replace the eval in OptionsCreator.py #5828

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions OptionsCreator.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -509,8 +509,10 @@ def randomize_option(instance: Widget, value: str):
self.options[name] = "random-" + str(self.options[name])
else:
self.options[name] = self.options[name].replace("random-", "")
if self.options[name].isnumeric() or self.options[name] in ("True", "False"):
self.options[name] = eval(self.options[name])
if self.options[name].isnumeric():
self.options[name] = int(self.options[name])
Copy link
Collaborator

@duckboycool duckboycool Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose this isn't a new issue, but .isnumeric() doesn't seem like the check that's actually wanted here. For instance, a Range that's set to a negative value and then toggled and untoggled random will end up being output as a string since something like "-1".isnumeric() gives False, although it should still work if from_any is used. If any int-castable value here should be accepted, that should be done by trying to do it in a try:.

I'd also be concerned about other similar issues when trying to determine type based just on string, although something like a choice called True seems to be spared by being lowercase.

Copy link
Collaborator

@silasary silasary Jan 12, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My preference is to use ast.literal_eval

Copy link
Contributor Author

@Mysteryem Mysteryem Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose this isn't a new issue

I'm not intending to change functionality here, I think that can be PR-ed separately.

preference is to use ast.literal_eval

I don't think ast.literal_eval is suitable. ast.literal_eval is intended for parsing ast nodes and strings containing arbitrary python literals as python code. By using ast.literal_eval, the code would be implying that it is expecting to parse arbitrary nodes or strings because that is the task ast.literal_eval is designed for. The actual task at hand is simpler, so should use simpler, more fitting tools.

elif self.options[name] in ("True", "False"):
self.options[name] = self.options[name] == "True"

base_object = instance.parent.parent
label_object = instance.parent
Expand Down
Loading