[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: Thanks Steve. Change applied, byebye python._pth. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Steve Dower added the comment: > starting with python-3.6.1rc Works with 3.6.0. The only relevant changes in 3.6.1 are to skip empty lines in the ._pth file, and to avoid overwriting sys.path[0] arbitrarily. -- ___ Python tracker

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: ok, I understand that the improvement over current solution is, starting with python-3.6.1rc: - remove "python._pth" - check I have a "Lib\os.py" (otherwise a "python36.zip"), - and no pixie dust here or there ? -- ___ Py

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Paul Moore added the comment: >> an alternative standalone Python interpreter > > It's a convenient way to avoid having your standard library hijacked by > registry keys installed by the regular interpreter. Ah yes, that makes sense - it's maybe not the *right* way, but as a practical approach

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Steve Dower added the comment: > an alternative standalone Python interpreter It's a convenient way to avoid having your standard library hijacked by registry keys installed by the regular interpreter. However, if it detects "Lib\os.py" or "python36.zip" alongside the executable, it shouldn't

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Paul Moore added the comment: It's probably worth also saying that maybe winpython shouldn't even be using the _pth file feature. I don't know why it is, but the intended use case for _pth files is embedded systems, so it's not clear how an alternative standalone Python interpreter matches tha

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Steve Dower added the comment: The semantics of the ._pth file won't be changing to accommodate security vulnerabilities, sorry. Add a sitecustomize.py file to modify sys.path if you want that behavior. -- ___ Python tracker

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: If I place a blank line or a semi-column, nothing happen. If i put my relative path ..\test, then I must do "import t1" If I set a __path__ in t2.py, then I have to do "from . import t1" "There should be one-- and preferably only one --obvious way to do it.", but I

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: or just I add a blank line in current python._pth and all is ok immediately ? -- ___ Python tracker ___ _

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: Hi Steve, Could there be a "" (or "@source" or whatever string) convention be added in python._pth to explicitely allow that "formerly default" situation ? It would not break anything backward, and allow again classic Python-3.5 code to work unchanged in all circ

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Steve Dower added the comment: The ._pth file is certainly not meant to cover beginner scenarios. But with that list of paths you should get almost exactly the same sys.path by default. Modifying a module's __path__ will only affect that module (and imports via that module), whereas sys.path a

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Paul Moore added the comment: No more so than any other method of adding entries to sys.path (which is what __path__ does for packages, I've just never seen it used for modules). -- ___ Python tracker

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: Using sys.path.append could result in an arbitrary long sys.path, full of duplicates, isn't it ? -- ___ Python tracker ___ _

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Paul Moore added the comment: I'm not sure about this, I've never seen __path__ used like this. Why can't you just set sys.path? sys.path.append(os.path.dirname(os.path.abspath(__file__))) That's how scripts typically adjust their search path if needed. -- ___

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: ok, I found this as a possible workaound. I hope it's correct on t2.py, specify the __path__ variable before importing t1. import os __path__=[os.path.dirname(os.path.abspath(__file__))] from . import t1 print("t2 done") --

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: and I fail to understand why IDLE doesn't feel the problem. -- ___ Python tracker ___ ___ Python-bugs-lis

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: The "targeted" user, a beginner in Python, will put its t1.py & t2.py examples anywhere on his disk, and discover that it doesn't work like in the book. It is very annoying for WinPython intended purpose, if a simple trick cannot provide the beginner "expected" beh

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Paul Moore added the comment: No (see the doc link I referenced) - paths are absolute, or relative to the _pth file. So "." means "in the same place as the pth file". I don't think there's a way with _pth files to get the "add the location of the executed script to the front of sys.path" behav

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Big Stone added the comment: doesn't the "." entry means "look at same place as current source file" ? Could there be a way to get that "classic" behavior on Python-3.6 ? -- ___ Python tracker

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Paul Moore added the comment: This sounds like a bug in winpython, not in Python itself. You need the location of t1.py in your _pth file. See https://docs.python.org/3.6/using/windows.html#finding-modules for details. Python 3.5 didn't use the _pth file mechanism, which is why the behaviour i

[issue29578] "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5

Changes by Big Stone : -- title: "python.exe t2.py" doesn't work the same on Pythn-3.6 as Python-3.5 -> "python.exe t2.py" doesn't work the same on Python-3.6 as Python-3.5 ___ Python tracker _