Mailman 3 March 2017 - docs

[issue29844] Windows Python installers not installing DLL to System32/SysWOW64
by Paul "TBBle" Hampson 19 Mar '17

19 Mar '17

Paul "TBBle" Hampson added the comment: If this is just a documentation fix, then there's two places that need it: * https://github.com/python/cpython/blob/master/Tools/msi/README.txt contains the text I quoted in the original report. * Some kind of release note (https://docs.python.org/3/whatsnew/3.5.html) so that things that have relied on this behaviour in the past (e.g. gvim with the Python3/dynamic build option) can have all their documentation updated to tell people to... I don't know? Grab the embedded version into the gvim install directory? What _is_ the recommended approach here, to give system-wide-installed applications access to a system-wide-installed Python environment? ============================================== I don't agree that this change is correct. It's inconsistent with the Linux experience of an all-users installation (i.e. anything on the system can link against libpython2.7.so and get the expected behaviour of using the system-installed Python) and I would also consider an All-Users install to *be* a system component, since the intent is clearly to make it available to all users and applications without further effort. Unlike putting python.exe in the path, the DLLs are version-named, so you don't suffer the conflict of *which Python* you get. The Python Launcher for Windows has taken care of that nicely, and if I have to add all the Python install directories to my path to ensure the DLLs are visible to applications that link against them, that seems to be a regression in the behaviour that launcher was trying to fix. An issue I see with the embedded installation approach is that if I want to make modules available to something like gvim's Python environment, then I need to maintain those modules distinctly from the modules I maintain on the system level. It also means I need to be modifying gvim's install directory to add that embedded distribution, and that leaves a whole bunch of manual tracking of installed things I need to worry about. I have the same concerns (manual tracking of things) if I have to add extra infrastructure to manage a copy of python3.X.dll in System32. Searching Google for this issue suggests that many people are just grabbing a random DLL off the internet named python3.5.dll and putting it in System32 when they encounter this problem, because "it used to work with Python 3.2". Alternatively... Does it make sense to have a "System Component" installer version of Python for use by other applications that want to offer (optional) Python interpreter support? It would be pretty-much identical to the installer we have now, except putting the DLL entry point (python3.x.dll) into the system path, but not having python.exe in the path to confuse command-line usage. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29844> _______________________________________

1 0

[issue29844] Windows Python installers not installing DLL to System32/SysWOW64
by Steve Dower 18 Mar '17

18 Mar '17

Steve Dower added the comment: I don't even think there's documentation to fix, the install page should say where things are installed. The system directory is for the system to install files - the Python installer is not a system component, it's a developer kit. For most cases, the install directory was "fixed" rather than broken. If you have particular needs to install a system-wide python3x.dll, I'd suggest crafting your own install script from the files in a normal install (though putting the install directory on PATH should also enable dependency resolution for most processes). ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29844> _______________________________________

1 0

[issue29844] Windows Python installers not installing DLL to System32/SysWOW64
by Eryk Sun 18 Mar '17

18 Mar '17

Eryk Sun added the comment: 3.5+ doesn't install files to system directories -- except the py launcher in %SystemRoot%. This was an intentional change, so I'm flagging this as a documentation issue. ---------- assignee: -> docs@python components: +Documentation, Windows keywords: +easy nosy: +docs@python, eryksun, paul.moore, steve.dower, tim.golden, zach.ware stage: -> needs patch versions: +Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29844> _______________________________________

1 0

[issue16355] inspect.getcomments() does not work in the interactive shell
by Berker Peksag 17 Mar '17

17 Mar '17

Berker Peksag added the comment: Now all PRs have been merged: * master: https://github.com/python/cpython/commit/3f2155ffe683080f2a1b28408fa48d43ba… * 3.6: https://github.com/python/cpython/commit/948171bf999cf8b3e12048851041d2e04a… * 3.5: https://github.com/python/cpython/commit/41b4a2189f29daae008e57f799a3089064… Thanks for the patches, Vajrasky and Marco! ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16355> _______________________________________

1 0

[issue16355] inspect.getcomments() does not work in the interactive shell
by Berker Peksag 17 Mar '17

17 Mar '17

Changes by Berker Peksag <berker.peksag(a)gmail.com>: ---------- pull_requests: +567 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16355> _______________________________________

1 0

[issue16355] inspect.getcomments() does not work in the interactive shell
by Berker Peksag 17 Mar '17

17 Mar '17

Berker Peksag added the comment: Please don't close an issue while there are still open backport PRs on GitHub. ---------- resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16355> _______________________________________

1 0

[issue16355] inspect.getcomments() does not work in the interactive shell
by Marco Buttu 17 Mar '17

17 Mar '17

Changes by Marco Buttu <marco.buttu(a)gmail.com>: ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16355> _______________________________________

1 0

[issue16355] inspect.getcomments() does not work in the interactive shell
by Berker Peksag 17 Mar '17

17 Mar '17

Changes by Berker Peksag <berker.peksag(a)gmail.com>: ---------- pull_requests: +565 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16355> _______________________________________

1 0

[issue28415] PyUnicode_FromFormat integer format handling different from printf about zeropad
by Xiang Zhang 17 Mar '17

17 Mar '17

Changes by Xiang Zhang <angwerzx(a)126.com>: ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue28415> _______________________________________

1 0

wrong output in example | 3.6/tutorial/introduction
by Igor Komyagin 16 Mar '17

16 Mar '17

Greetings. I have found the wrong output on page https://docs.python.org/3.6/tutorial/introduction.html in the example: *This only works with two literals though, not with variables or expressions:* *>>>* *>>> prefix = 'Py' >>> prefix 'thon' # can't concatenate a variable and a string literal ... SyntaxError: invalid syntax >>> ('un' * 3) 'ium' ... * *SyntaxError: invalid syntax * Right output should be: >>> prefix = 'Py' >>> prefix 'thon' File "<stdin>", line 1 prefix 'thon' ^ SyntaxError: invalid syntax It looks like a pretty easy fix. Feel free to contact me for further information. Best regards, Igor Komyagin

1 0