On Sun, Jan 12, 2020 at 6:38 PM Steven D'Aprano <st...@pearwood.info> wrote: > > On Sun, Jan 12, 2020 at 11:59:20AM +1100, Chris Angelico wrote: > > > The biggest difference is that scripts can't do relative imports. > > How is that relevent? People keep mentioning minor differences between > different ways of executing different kinds of entities (scripts, > packages, submodules etc) but not why those differences are important or > why they would justify any change in the way -m works. > > A script can't do relative imports because they aren't packages and so > don't have any submodules that they could do a relative import of. > > If relative imports are important to you, why not use a package?
Have done so. The net result is often that there's a shim script that has no purpose but to adjust the path and import a module, and an extra directory level between that and the "real" code. > > 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). > > I wish people wouldn't jump straight to proposing solutions before they > have articulated the specific nature of the problem they wish to solve > first :-( The problem is that there's a stark division between scripts and modules, and a directory is kinda a package, but kinda not. Compare: On Sun, Jan 12, 2020 at 10:34 AM Andrew Barnert via Python-ideas <python-ideas@python.org> wrote: > Any directory is a package. ... If it doesn’t have an __init__.py, it’s a > namespace package, which is still a package. So if a directory is a package, but a script in a directory isn't a module in a package, what gives? Wouldn't it be cleaner if a script in a directory could do a relative import, given that directories ARE capable of behaving as packages? > Even if the problem is blindingly obvious to (generic) you, it may not > be obvious to all of us. We shouldn't get twenty posts into a thread > and have the problem being solved still be unclear. Fair point. Hopefully I've clarified it above. > Why is it necessary to use a relative import in a non-package script? Is > this a way to solve name collisions? > > "I want a script spam.py that depends on a module X.py, but X clashes > with a standard library module, and I need both the stdlib X and the > local X." It's about clarity and potential forward compatibility. Imagine if someone had a "secrets.py" containing their encryption keys and whatnot, and then used "import secrets" to load it up. This code would continue to run successfully when the stdlib gained its own secrets module, but could potentially break depending on import order and other imports. If, instead, the normal thing to do is "from . import secrets", then there's no conflict ever, and the intent is very clear - this should be imported from the surrounding package directory, not searched for along sys.path. Remember, sys.modules is global, so "I need both stdlib and local" might actually mean "I need my local module, but something that I import indirectly needs the stdlib one". And clashes are hard to debug. 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/ZWJRZTEBZ5OFVPZTJTUZTEESKWZDS3IR/ Code of Conduct: http://python.org/psf/codeofconduct/
