If you use "from __future__ import division" then "1/2" returns 0.5.
Note that it's still possible to do evil things like cos.__class__.__bases[0].__subclasses__() and get access to other types in the system, or create a list comprehension which grabs a huge amount of memory.
Yes, the __future__ affects all eval and exec statements inside that module, and only that module. But that change actually affect other code in the module? If so, move the eval code into its own module. That would isolate the problem.
You can't search for "__" because someone can use "_"+"_" or even "_" "_" because of the implicit string concatenation by the parser.
Comment
If you use "from __future__ import division" then "1/2" returns 0.5.
Note that it's still possible to do evil things like cos.__class__.__bases[0].__subclasses__() and get access to other types in the system, or create a list comprehension which grabs a huge amount of memory.
Replies
How does that work? If I do that import won't it taint the rest of the module? (at the moment I have my function 'calc()' in a file called utils.py
About the dunder __, I'll just kick that out with a search for the string '__'
Yes, the __future__ affects all eval and exec statements inside that module, and only that module. But that change actually affect other code in the module? If so, move the eval code into its own module. That would isolate the problem.
You can't search for "__" because someone can use "_"+"_" or even "_" "_" because of the implicit string concatenation by the parser.