[issue43278] unnecessary leading '\n' from Py_GetCompiler() when build with different complier
Change by Joseph Shen : -- nosy: +benjamin.peterson ___ Python tracker <https://bugs.python.org/issue43278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43278] unnecessary leading '\n' from Py_GetCompiler() when build with different complier
Joseph Shen added the comment: Right now there is no need to keep this limits, and the __version__ info from GCC is quite simple. Pls the attached snapshot image. Therefor I don't think we should keep a commit from 2000. -- ___ Python tracker <https://bugs.python.org/issue43278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43278] unnecessary leading '\n' from Py_GetCompiler() when build with different complier
Change by Joseph Shen : -- title: Inconsistent behavior of Py_GetCompiler() -> unnecessary leading '\n' from Py_GetCompiler() when build with different complier ___ Python tracker <https://bugs.python.org/issue43278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43278] Inconsistent behavior of Py_GetCompiler()
Change by Joseph Shen : -- keywords: +patch pull_requests: +23384 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24606 ___ Python tracker <https://bugs.python.org/issue43278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43278] Inconsistent behavior of Py_GetCompiler()
New submission from Joseph Shen : The function Py_GetCompiler() return the version info with a leading '\n' when build with GCC/clang, while without this on other compilers. This inconsistent make the REPL print the 'welcome message' quit different, which I think is not we expect. >From the snapshot images, we can see, when compiler with MSVC, the 'welcome >message' has two lines, but with GCC it is 3 lines, which two lines is what >expected. Patch is given in the github rp, thanks for review. -- components: C API files: explorer_lN3ARB7gnj.png messages: 387417 nosy: josephsmeng priority: normal pull_requests: 23377 severity: normal status: open title: Inconsistent behavior of Py_GetCompiler() type: behavior Added file: https://bugs.python.org/file49824/explorer_lN3ARB7gnj.png ___ Python tracker <https://bugs.python.org/issue43278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30670] pprint for dict in sorted order or insert order?
Joseph Shen added the comment: I reopened this issue, and change affected versions to 3.6, 3.7 and 3.8. -- status: closed -> open versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue30670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30670] pprint for dict in sorted order or insert order?
New submission from Joseph Shen: start from 3.6+, dict keys are ordered heir creation order. the builtin print function works as we expected, but for pprint, the keys is sorted. should we using the sorted version or just obey the creation order as builtin print? -- components: Library (Lib) messages: 296056 nosy: josephsmeng priority: normal severity: normal status: open title: pprint for dict in sorted order or insert order? type: behavior versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29080] unnecessary hg required for build version 3.6 on Windows
New submission from Joseph Shen: the released 3.6.0 PCbuild/build.bat required hg for building. but this requirement is not necessary for build python from source. maybe it will be better for us to remove this requirement as the old versions. -- components: Build messages: 284078 nosy: Joseph.Shen priority: normal severity: normal status: open title: unnecessary hg required for build version 3.6 on Windows type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
Joseph Shen added the comment: Oh, can't believe this, and I thought iPhone 8 will bring back my lovely 3.5mm jack ^_^ On Sat, Sep 10, 2016 at 22:16 Zachary Ware <rep...@bugs.python.org> wrote: > > Zachary Ware added the comment: > > Joseph: "plat-win" was actually removed from the comment in #28046; it is > an obsolete name that hasn't been used since August 21, 2000. I just > killed the platform directories, let's not bring them back :) > > -- > > ___ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue27874> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
Joseph Shen added the comment: Yeah it's true, anyway thanks for your support On Sat, Sep 10, 2016 at 22:10 Steve Dower <rep...@bugs.python.org> wrote: > > Steve Dower added the comment: > > I don't intend to change any defaults arbitrarily, but you can easily > specify a folder with whatever name you like for these. I agree it would be > a more sensible name, but it's such a minor issue that change would be more > disruptive than helpful. > > -- > > ___ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue27874> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
Joseph Shen added the comment: I noticed someone use `plat-win` instead of `DLLs` in this http://bugs.python.org/issue28046, so what's your opinion for this? `plat-win` looks more meaningful than old `DLLs` at least for me, do your have any plan for this in the 3.6 release? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
Joseph Shen added the comment: thanks for the comment and make python work on Windows better :) I will trace the 3.6 source code. On Sat, Aug 27, 2016 at 8:58 PM Steve Dower <rep...@bugs.python.org> wrote: > > Steve Dower added the comment: > > I don't entirely agree with the analysis or suggestions here, but I do > intend to change this for 3.6 so I'll assign myself. At the very least, we > won't fall back on totally relative paths - we'll make them absolute from > the program directory. > > -- > assignee: -> steve.dower > resolution: not a bug -> > stage: resolved -> needs patch > versions: +Python 3.6 -Python 3.5 > > ___ > 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
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
Joseph Shen added the comment: I don't know how to reopen this issue, please make some comments for what I added just now, thanks. -- status: closed -> open ___ 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
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
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, \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
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
Joseph Shen added the comment: second snapshot -- Added file: https://bugs.python.org/file44239/2016-08-27_15-09-45.png ___ 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
[issue27874] inconsistent sys.path behavior when using PythonXX.zip
New submission from Joseph Shen: Found a inconsistent sys.path result when python packed with it's library with zip package. A. when NOT use zip package sys.path is base the python.exe's absolute path, result is 1. ABS_PATH\pythonXX.zip 2. ABS_PATH\DLLs 3. ABS_PATH\lib, 4. ABS_PATH 5. ABS_PATH\lib\site-packages B. when use zip package sys.path is base the relative path of call path, result is 1. ABS_PATH\pythonXX.zip 2. RLT_PATH\DLLs 3. RLT_PATH\lib, 4. ABS_PATH this is not commonly expected for the `DLLs` and `lib`, I think the result will still be absolute path for where the executable located. I snapshot two pictures for this problem, please review this, thanks. -- components: Windows files: 2016-08-27_15-09-39.png messages: 273763 nosy: Joseph.Shen, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: inconsistent sys.path behavior when using PythonXX.zip type: behavior versions: Python 3.5 Added file: https://bugs.python.org/file44238/2016-08-27_15-09-39.png ___ 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
[issue21713] a mistype comment in PC/pyconfig.h
New submission from Joseph Shen: in the source file PC/pyconfig.h at line 393 there is a mistype this is the origin file == /* VC 7.1 has them and VC 6.0 does not. VC 6.0 has a version number of 1200. Microsoft eMbedded Visual C++ 4.0 has a version number of 1201 and doesn't define these. If some compiler does not provide them, modify the #if appropriately. */ #if defined(_MSC_VER) #if _MSC_VER 1300 #define HAVE_UINTPTR_T 1 #define HAVE_INTPTR_T 1 #else /* VC6, VS 2002 and eVC4 don't support the C99 LL suffix for 64-bit integer literals */ #define Py_LL(x) x##I64 #endif /* _MSC_VER 1200 */ #endif /* _MSC_VER */ #endif == #endif /* _MSC_VER 1200 */ should be #endif /* _MSC_VER 1300 */ or left empty -- components: Windows messages: 220223 nosy: Joseph.Shen priority: normal severity: normal status: open title: a mistype comment in PC/pyconfig.h type: compile error versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21713 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
