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

[Big Stone]

Big Stone added the comment:

Thanks Steve.

Change applied, byebye python._pth.

--

___
Python tracker 

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

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

[Steve Dower]

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 

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

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

[Big Stone]

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 ?

--

___
Python tracker 

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

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

[Paul Moore]

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

--

___
Python tracker 

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

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

[Steve Dower]

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

--

___
Python tracker 

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

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

[Paul Moore]

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

--

___
Python tracker 

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

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

[Steve Dower]

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 

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

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

[Big Stone]

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

--

___
Python tracker 

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

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

[Big Stone]

Big Stone added the comment:

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

--

___
Python tracker 

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

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

[Big Stone]

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 circumstances (of WinPython) again.



in python-3.6.1 ?

--

___
Python tracker 

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

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

[Steve Dower]

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

--

___
Python tracker 

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

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

[Paul Moore]

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 

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

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

[Big Stone]

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 

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

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

[Paul Moore]

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.

--

___
Python tracker 

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

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

[Big Stone]

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

--

___
Python tracker 

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

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

[Big Stone]

Big Stone added the comment:

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

--

___
Python tracker 

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

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

[Big Stone]

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

--

___
Python tracker 

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

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

[Paul Moore]

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

--

___
Python tracker 

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

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

[Big Stone]

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 

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

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

[Paul Moore]

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

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

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

[Big Stone]

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 

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