Joseph Shen added the comment: Yea, thanks for review, I knew the pyven. But the behavior right now is really what I think unnecessary complicated and confusing. What I think, we all knew the DLLs is used for python keep the *.pyd (actually just dll), so by default, why we want this directory relative to the working directory? indeed the configure file can fix this, but is this process really what we needed? we need check the PYTHONHOME , read the registy, check if the configure file exist, just for make python find the libraries? I knew python has a long history for keep the library path environment variable work right, and not even mention pyenv and some other tools, but this just make things more complicated.
So, as a conclusion, I think we should make the sys.path consistent with or without using zip packed library, especially for the DLLs if we think about some backward compatibility.fix this is just a small step for making python application launch faster and packing simpler. Thanks, I think this problem still arguable. On Sat, Aug 27, 2016 at 17:38 Eryk Sun <rep...@bugs.python.org> wrote: > > Eryk Sun added the comment: > > Windows Python determines sys.prefix (i.e. the location of the standard > library, <prefix>\lib) via either the PYTHONHOME environment variable or by > searching for the landmark "lib/os.py", starting in the application > directory and reducing back to the root directory [1]. > > If it can't find the prefix directory; PYTHONPATH isn't defined; and it > can't find PythonPath in the registry; then it adds the "DLLs" and "lib" > directories relative to the working directory. This default PYTHONPATH is > defined in PC/pyconfig.h as ".\\DLLs;.\\lib". > > There is an alternative "applocal" (application local) mode. Create a file > named pyvenv.cfg beside python.exe that contains the single line > > applocal = true > > This prevents Python from checking PYTHONHOME and PYTHONPATH, the > registry, and prevents searching for the "lib/os.py" landmark. sys.prefix > is set as the application directory, and the default "DLLs" and "lib" paths > are expanded relative to the application directory. > > Anyway, since what you're reporting is the expected behavior, I'm closing > this issue. Feel free to reopen it if you feel I've misdiagnosed the > problem or think the default behavior is somehow broken. I don't know what > Steve Dower's plans are, if indeed he has any, to change the legacy > sys.path behavior in future releases. > > > [1]: The reduce() function in PC/getpathp.c has a minor bug that > results in sys.prefix set as the drive-relative path "C:" if > the landmark search continues to the root and "C:/lib/os.py" > exists. This is due to the way it overwrites the path separator > with NUL to reduce the path. I think it should keep the > separator. The join() function works either way. > > ---------- > nosy: +eryksun > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <https://bugs.python.org/issue27874> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27874> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
