[issue29929] Eliminate implicit __main__ relative imports

[Ronald Oussoren]

Ronald Oussoren added the comment:

If only someone had access to the time machine keys to fix this 20 year ago 
:-(. Anything beyond that last option (recognising that the script tries to 
import itself under another name) is bound to run into odd issues or backward 
compatibility concerns.

Just recognising a reimport of __main__ should avoid a lot of confusion though, 
from what I've seen in discussions most cases of unintentional shadowing of the 
stdlib is caused by folks naming a exploratory script the same as a stdlib 
module (e.g. naming a script "socket.py" when experimenting with sockets).

W.r.t. "from . import ..." and scripts: installing using entry points isn't a 
problem, but installing using plain distutils still is as is the even more 
low-tech option of just copying files to the right location (maybe using a 
Makefile).  But that issue is moot now that Guido has stated he doesn't like 
the idea.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29929] Eliminate implicit __main__ relative imports

[Nick Coghlan]

Nick Coghlan added the comment:

Ronald: that depends somewhat on how the installation is handled. For example, 
for entrypoints-style scripts, the entirety of __main__ is auto-generated 
anyway, and anyone using "./setup.py develop" or "pip install -e ." to add a 
suitable sys.path entry during development will still be able to do "import 
helper" regardless of what happens to sys.path by default.

However, Guido has stated he doesn't like the idea of requiring beginners to 
learn the "from . import helper" construct, so I think that's enough to kill 
that particular proposed solution to the problem described in my opening 
message.

Another solution proposed on python-ideas was to move the script directory to 
the *end* of sys.path rather than having it at the beginning, but the problem 
with that is that it not only cripples our ability to add new modules to the 
standard library, but it also greatly increases the odds of additions to 
site-packages by redistributors breaking end user scripts. As things currently 
stand, the name shadowing caused by such additions only needs to be resolved by 
projects that actually want to access the standard library or redistributor 
provided module. By contrast, if the script directory were added at the end of 
sys.path, then those scripts would outright break as they'd start getting the 
newly added module rather than the peer module they were expecting.

Eliminating both of those more general approaches pretty much leaves us with 
the one more narrowly focused option: when an import candidate matches 
`__main__.__spec__.origin`, we start ignoring it with a silent-by-default 
ImportWarning and move on. To avoid breaking imports when using the -m switch 
we'd likely need to accept PEP 499 as well, but I was generally inclined to do 
that anyway (I just hadn't gotten around to offering to be BDFL-Delegate for 
that PEP as the runpy module maintainer yet)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29929] Eliminate implicit __main__ relative imports

[Ronald Oussoren]

Ronald Oussoren added the comment:

A disadvantage of requiring "from . import ..." to import modules next to the 
script is that this requires a different mechanism before and after 
installation of a script.

That is, before installation the additional modules are next to the script 
("from . import helper" and after installation the additional modules are in 
site-packages while the script itself is in the bin directory ("import helper").

--
nosy: +ronaldoussoren

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29929] Eliminate implicit __main__ relative imports

[Chris Angelico]

Changes by Chris Angelico :


--
nosy: +Rosuav

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29929] Eliminate implicit __main__ relative imports

[Nick Coghlan]

Nick Coghlan added the comment:

See https://mail.python.org/pipermail/import-sig/2017-March/001068.html for the 
above-mentioned import-sig post (the design in that email isn't the same as the 
one described above, but later in the thread I decided the design suggested 
here is likely to be less confusing overall)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29929] Eliminate implicit __main__ relative imports

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29929] Eliminate implicit __main__ relative imports

[Nick Coghlan]

Nick Coghlan added the comment:

In formulating a post to import-sig about this, I realised it made more sense 
to describe it in terms of the goal (eliminating implicit __main__ relative 
imports) rather than one possible technique for achieving that goal.

--
title: Idea: Make __main__ an implied package -> Eliminate implicit __main__ 
relative imports

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com