Skip to content
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.

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

Add filename to exec/eval and parse to eval #26

Merged
merged 1 commit into from
Apr 18, 2022

Conversation

jordemort
Copy link
Contributor

These methods now accept a filename parameter, which will be used to
set the filename attribute on any resulting SyntaxError objects.

eval now accepts a parse parameter; if it is not True, then eval
will return a string containing the unparsed expression.

This also adds a bunch of tests for parsing, in preparation for moving
away from ast.literal_eval and building Python data structures directly
in a subsequent pull request.

These methods now accept a `filename` parameter, which will be used to
set the `filename` attribute on any resulting `SyntaxError` objects.

`eval` now accepts a `parse` parameter; if it is not True, then eval
will return a string containing the unparsed expression.

This also adds a bunch of tests for parsing, in preparation for moving
away from ast.literal_eval and building Python data structures directly
in a subsequent pull request.
@jordemort jordemort merged commit 66833e7 into main Apr 18, 2022
@jordemort jordemort deleted the add-filename-and-parse-kwargs branch April 18, 2022 21:02
jordemort added a commit that referenced this pull request Apr 18, 2022
In #26 another change snuck
in to retain the globals across multiple calls to exec, so that it
could be used to define multiple things. While writing a test for this
behavor, I discovered that it is possible for starlark-go's Eval to
return a resolve.ErrorList, in addition to a starlark.EvalError or
a syntax.Error, so I had to add handling for that as well.
jordemort added a commit that referenced this pull request Apr 18, 2022
In #26 another change snuck
in to retain the globals across multiple calls to exec, so that it
could be used to define multiple things. While writing a test for this
behavor, I discovered that it is possible for starlark-go's Eval to
return a resolve.ErrorList, in addition to a starlark.EvalError or
a syntax.Error, so I had to add handling for that as well.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant