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