Hi,

I have two file "t1.py" and "t2.py" in the same directory. "t2.py" can't import "t1.py" when launched from python.exe on Python-3.6. it was ok on Python-3.5 (all other things being equal). And it's ok when launched from IDLE.

Has there been a volontary change ?
t1.py:
print("i am t1")

t2.py:
import t1
print("I am t2")

result (on WinPython-3.6):
python.Exe C:\WinPython\basedir36\buildZero\winpython-64bit-3.6.x.2\test\t2.py

Traceback (most recent call last):
  File "C:\WinPython\basedir36\buildZero\winpython-64bit-3.6.x.2\test\t2.py", line 1, in <module>
    import t1
ModuleNotFoundError: No module named 't1'

C:\WinPython\basedir36\buildZero\winpython-64bit-3.6.x.2\scripts>

nota: Winpython specificity is the use of python._pth, with:
python36.zip
DLLs
Lib
.
import site

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 is different.

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 ?

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" behaviour. It's not really a good idea for an embedded interpreter (which is the _pth file intended use case) as it makes it a bit too easy to run code from unexpected locations.

In an embedded application, you could of course add sys.path entries in your C code. Maybe WinPython could do that too?

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" behavior.

and I fail to understand why IDLE doesn't feel the problem.

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")

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.

Using sys.path.append could result in an arbitrary long sys.path, full of duplicates, isn't it ?

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).

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 affects your entire program. Adding an empty string to either should give you the default behavior back, but this is specifically not supported by ._pth.

Hi Steve,

Could there be a "<blank>" (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 circumstances (of WinPython) again.



in python-3.6.1 ?

or just I add a blank line in current python._pth and all is ok immediately ?

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 don't clearly see it.

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.

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 that scenario...

> 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 look in the registry to figure out its home directory. That ought to be sufficient for portable cases, though of course there are some registry entries that will still have an impact (until 3.6.1, when we should be registry clean provided one of the landmark files is found).

>> 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 it has benefits :-)

> However, if it detects "Lib\os.py" or "python36.zip" alongside the executable, it shouldn't look in the registry to figure out its home directory. That ought to be sufficient for portable cases, though of course there are some registry entries that will still have an impact (until 3.6.1, when we should be registry clean provided one of the landmark files is found).

And that of course is the "right" way - it's just taken a long time to
get there because of all the nastiness involved in interpreter startup
(see PEP 432 :-))

I'd forgotten (and hadn't gone and checked) that WinPython was
designed as a portable build.

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 ?

> 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.

Thanks Steve.

Change applied, byebye python._pth.