I really don't want people to start using the "from . import foo" idiom for their first steps into programming. It seems a reasonable "defensive programming" maneuver to put in scripts and apps made by professional Python programmers for surprise-free wide distribution, but (like many of those) should not be part of the learning experience.
On Sun, Jun 4, 2017 at 12:35 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 4 June 2017 at 10:00, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > > Is this really much of a security issue? Seems to me that > > for someone to exploit it, they would have to inject a > > malicious .py file alongside one of my script files. If > > they can do that, they can probably do all kinds of bad > > things directly. > > There are genuine problems with it, which is why we have the -I switch > to enable "isolated mode" (where pretty much all per-user settings get > ignored). However, just dropping the current directory from sys.path > without also disabling those other features (like user site-packages > processing and environment variable processing) really doesn't buy you > much. > > So the better answer from a security perspective is PEP 432 and the > separate system-python binary (and Eric Snow recently got us started > down that path by merging the initial aspects of that PEP as a private > development API, so we can adopt the new settings management > architecture incrementally before deciding whether or not we want to > support it as a public API). > > So rather than anything security related, the key reasons I'm > personally interested in moving towards requiring main-relative > imports to be explicit are a matter of making it easier to reason > about a piece of code just by reading it, as well as automatically > avoiding certain classes of beginner bugs (i.e. essentially the same > arguments PEP 328 put forward for the previous switch away from > implicit relative imports in package submodules: > https://www.python.org/dev/peps/pep-0328/#rationale-for-absolute-imports). > > Currently, main relative imports look like this: > > import helper > > This means that at the point of reading it, you don't know whether > "helper" is independently redistributed, or if it's expected to be > distributed alongside the main script. > > By contrast: > > from . import helper > > Makes it clear that "helper" isn't a 3rd party thing, it's meant to be > distributed alongside the main script, and if it's missing, you don't > want to pick up any arbitrary top level module that happens to be > called "helper". > > Reaching a point where we require main relative imports to be written > as "from . import helper" also means that a script called "socket.py" > could include the statement "import socket" and actually get the > standard library's socket module as it expected - the developer of > such a script would have to write "from . import socket" in order to > reimport the main script as a module. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
