Moreover, being able to do it programmatically is a security risk, since it requires elevated privileges that I don't know how to drop, and most people will not think about doing, but a library implementation will. So if someone uses subprocess.run(), and the system asks the user for elevated privileges, a bug in later code can easily cause serious harm instead of failing. Yes, untrusted code should be sandboxed - but it isn't, more often than not. Elazar On Tue, Sep 20, 2016 at 2:02 PM אלעזר <elazarg@gmail.com> wrote:
I think I generally understand concerns, and partially agree. I'm certainly not dismissing them. I only try to understand what are the precise problems and why the current situation - with dangerous functions at reach, easily buried deep in the code instead of marked on the top of the script - is so much better.
Elazar
On Tue, Sep 20, 2016 at 1:56 PM Paul Moore <p.f.moore@gmail.com> wrote:
On 20 September 2016 at 11:46, אלעזר <elazarg@gmail.com> wrote:
So it should be something like
from unsafe.__pip__ import benchmark
Where unsafe is the hypothetical namespace in which exec(), eval() and subprocess.run() would have reside given your concerns.
In my opinion, it should be
# Please install benchmark using pip to run this script
Or you should run the script using a dedicated runner like rwt. Or you can depend on a custom import hook that makes "from __pip__ install..." work as you want. I'm just saying that I don't want core Python to implicitly install packages for me. But that's simply a personal opinion. I'm not trying to persuade you you're wrong, just trying to explain my position. We can agree to differ. It certainly doesn't seem to me that there's any need for you to modify your proposal to suit me, it's unlikely I'll like any variation you're going to be happy with, which is fine (you're under no obligation to convince me).
Paul