On 9 March 2016 at 04:47, Brett Cannon firstname.lastname@example.org wrote:
But if you drop the directory that a script is contained in, how do you import any packages that are in that directory? What about __main__.py files in the top directory of code checkouts for easy testing of making executable zipfiles? It's a slippery slope, hence why the semantics have not changed.
It's also not uncommon for setup.py files to expect to be able to import the package they relate to.
Accordingly, the proposal I'm most amenable to is the one to simply change the default precedence of the current directory on sys.path by moving it to the end of the filesystem search (after the standard library, site-packages, user site-packages, etc). This wouldn't affect the -m switch (or the runpy module in general), since that manipulates sys.path directly, and would mean creating a "socket.py" script to experiment with the socket modules would "just work".
Such a change poses its own compatibility problems (relating not only to deliberate shadowing of installed modules, but also to software that assumes the first entry in sys.path is the current directory or the script directory and removes it), but such software is already broken when run in isolated mode (which entirely skips adding the current/script directory to sys.path), so pushing folks to find more robust approaches to handling such cases wouldn't be a bad thing.
From a practical implementation perspective, one possible approach
would be to handle this as a second PathImporter on sys.meta_path (after the regular sys.path one), and lose the current/script directory entry from sys.path. That way the impact on other sys.path manipulation code would be minimal - the rest of the startup sequence could continue to just append to sys.path as it does today.
The compatibility break (even if only in limited circumstances) means any such change *would* require a PEP (and probably a way to opt back in to the old behaviour), but the fact this is also an opportunity to *simplify* the implementation (by giving the current/script directory a dedicated meta_path entry rather than using a special token in sys.path) makes me at least willing to consider the idea.