Daniel

Hi! Thanks for this - but could you show how these could be abused to allow a backdoor? Currently they are parsed, but should not be able to be used...

Hi @KOLANICH ! Thanks for the analysis. Yes, I totally agree, a whitelist approach is a better overall solution. I've been thinking for a while that the best approach is...

>> Currently they are parsed, but should not be able to be used maliciously. > Is there any proof of that? Not in a formal mathematical sense 😄 But for...

This is cool! Thanks @smurfix

> @danthedeckie any reason why this doesn't get merged, other than "too much other stuff on your plate"? (Happens to the best …) Exactly that - 😬 ! I've starting...

Cool idea! I hadn't thought of doing multiple runs on different data. I'm exploring this a bit on the Dev branch.

@daveisfera Would https://github.com/danthedeckie/simpleeval/tree/warn_on_assign work for you? As in, not mess up your workflow. It could actually raise an exception which you then over-ride, but I don't want to introduce changes...

@PPakalns that sounds great! Thanks for wanting to be part of this 😄

Hi Rod, Thanks for your kind words. Yeah, the operators and functions parameters are a bit ugly, it must be said. They do completely over-ride the defaults, rather than appending....

Oh, and I had another thought... If you then want to get rid of the ^func^ Xor wings, since we're now in plain text land, you can use a string...