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, 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.


‪On Tue, Sep 20, 2016 at 2:02 PM ‫אלעזר‬‎ <> 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 <> wrote:
>> On 20 September 2016 at 11:46, אלעזר <> wrote:
>> > So it should be something like
>> >
>> > from unsafe.__pip__ import benchmark
>> >
>> > Where unsafe is the hypothetical namespace in which exec(), eval() and
>> > 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
Python-ideas mailing list
Code of Conduct:

Reply via email to