On Sun, Jan 12, 2020 at 12:30 PM Juancarlo Añez <apal...@gmail.com> wrote:
>>
>> The biggest difference is that scripts can't do relative imports. So
>> here's a counter-proposal: Allow "from . import modulename" to import
>> "modulename.py" from the directory that contains the script that
>> Python first executed (or, for interactive Python, the current
>> directory as Python started).
>
>
> Understanding "script" as a free standing ".py"...
>
> I loved your suggestion because of it's convenience, but I worry it could be
> a security hole. I have scripts in ~/bin, in ./bin, and in ./scripts.
How is this a security hole? If anything, it's LESS of a security
hole. Consider:
$ echo 'print("You got p0wned")' >re.py
$ echo 'import re' >demo.py
$ python3 demo.py
You got p0wned
That can ALREADY happen, and it's possible for a script to shadow
something from the stdlib. You can even trigger this indirectly - for
instance, attempting to import argparse will cause re to be imported.
Using "from . import modulename" implies that you specifically do NOT
want to load up a module based on sys.path, but are looking for one in
the current package's directory. That almost certainly means that such
a file will indeed exist, so there's a few attack surfaces closed off.
(For the record, I'm not complaining about the status quo, nor
proposing this as any sort of "solution" to a "problem". Just saying
that it isn't creating any problem that doesn't already exist.)
ChrisA
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/SD6ZGULPTZKNYE4POAI5C3HLP6TFH3K4/
Code of Conduct: http://python.org/psf/codeofconduct/
