Eval, literal eval, safe eval
Mark S. Miller
erights at google.com
Sun Nov 23 08:22:16 PST 2014
needs updating in light of modern promises, but see discussion of Vats and
On Sun, Nov 23, 2014 at 3:27 AM, Michał Wadas <michalwadas at gmail.com> wrote:
> - eval executes piece of code
> - eval can not be safely used with external input
> - Python's ast.literal_eval would be almost useless in modern
> literal_eval description:
> >The string or node provided may only consist of the following Python
> literal structures: strings, numbers, tuples, lists, dicts, booleans, and
> My proposition is "safe eval".
> Safe eval ( eval.safe(string: code, callback) ) should perform theses
> - Create isolated realm without capabilities to perform almost any IO
> (implementation dependant - no XHR, no importScript, no require)
> - evaluate code in context of created realm
> - post result of last evaluated expression back to creator realm using
> structured-clone algorithm
n. Structured clone sucks.
> - call callback with returned data
Prefer promises to callbacks
> + sandbox offered by language
y. Plan is to refine Realm API for ES7 by trying to redo SES in terms of
> + easy to run in other thread
> + quite easy to polyfill
Well, it wasn't as easy as I first expected, but we do have a SES polyfill.
Not yet for Vats or Dr. SES
> + servers can send computations to users
> - Realm creation can be costly (but implementations can solve this
> problem in many ways)
> - proposal does not include support for asynchronous operations
Dr. SES does.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss