Do not allow assignment operator

[PPakalns]

The following statement successfully executes.

simpleeval.simple_eval("a = 2")

And returns 2.
I suggest that assignment operator is entirely disallowed as input to simple eval.

Because "a == 2" can be easily mistyped as "a = 2" and existence of variable "a" is not even checked in evaluation of this input.

[daveisfera]

We currently use this functionality and prefer that it continue to be allowed ( see #25 (comment) )

[PPakalns]

We currently use this functionality and prefer that it continue to be allowed ( see #25 (comment) )

(Is the provided comment the correct one?)

We can add this validation as optional. Anyway, this assignment thing should be handled in better way because as it is now the assignment target can be anything (variable name is not used anywhere) and can easily introduce errors if second equality sign is missed.

[daveisfera]

Yes, that's the comment that I intended to link to but it doesn't tell the whole story. We actually use simpleeval in a wrapper (called ComplexEval as a sort of joke) that allows it to run multi-line Python expressions so it's a sort of Python sandbox. So assignments are a crucial part of that and make it so that the sandbox can actually "do something". There's probably some protections that could be put in around that (i.e. only allow assignment to exist variables in some cases), but for us the current setup works very well.
I'd be willing to contribute that wrapper upstream, if there's interest in adding it to this module.

[danthedeckie]

@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 to current behaviour unless it really makes sense to.

I've realised that I've really not done a great job up til now of maintaining this.

I want to improve that in the future - but it will mean some breaking changes, so my ideal plan at the moment is to lock it down to a 1.0 "stable" release, and then do some refactoring & sanifying (if that's a word) as a 2.0 branch

[PPakalns]

@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 to current behaviour unless it really makes sense to.

I've realised that I've really not done a great job up til now of maintaining this.

I want to improve that in the future - but it will mean some breaking changes, so my ideal plan at the moment is to lock it down to a 1.0 "stable" release, and then do some refactoring & sanifying (if that's a word) as a 2.0 branch

I believe that 2.0 version is good idea because a lot of changes looks like breaking ones.
It would be good to identify the main needed features for the new release in a separate issue.
At least I would like to provide some input for it :)

[danthedeckie]

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

[daveisfera]

Yes, that would be fine because I should be able to override with functions that do the assignment in my "complex wrapper"

[jeffreyscottgraham]

I use the assignment. Please dont remove. Optional is fine with me.
How do I turn off the warning about assignment?