On Sun, Jan 12, 2020 at 12:30 PM Juancarlo AƱez <apalala@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