[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:

[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

[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/issu

[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/issu

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

[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/issu

[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

[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

[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 actua

[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

[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

[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

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

[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

[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/i

[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

[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