[issue2142] difflib.unified_diff(...) produces invalid patches
Paul "TBBle" Hampson added the comment: I just bounced off this issue and proposed a work-around for it in Black (https://github.com/psf/black/pull/1897). Since it wasn't mentioned here earlier, the `\` marker _is_ documented in the GNU Diffutils documentation, under "Incomplete Lines" (https://www.gnu.org/software/diffutils/manual/html_node/Incomplete-Lines.html#Incomplete-Lines), and applies to both Context and Normal diff output formats. -- nosy: +TBBle ___ Python tracker <https://bugs.python.org/issue2142> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29844] Windows Python installers not installing DLL to System32/SysWOW64
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 <rep...@bugs.python.org> <http://bugs.python.org/issue29844> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29844] Windows Python installers not installing DLL to System32/SysWOW64
Changes by Paul "TBBle" Hampson <paul.hamp...@pobox.com>: -- components: +Installation type: -> behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29844> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29844] Windows Python installers not installing DLL to System32/SysWOW64
New submission from Paul "TBBle" Hampson: As noted in https://github.com/python/cpython/tree/master/Tools/msi === When installed for all users, the following files are installed to either "%SystemRoot%\System32" or "%SystemRoot%\SysWOW64" as appropriate. For the current user, they are installed in the Python install directory. .\python3x.dll The core interpreter .\python3.dll The stable ABI reference === However, at least with the Python 3.5.3 and Python 3.6.0 installers from the official download page, even an all-users install puts the relevant DLLs in the installation directory instead. This is the both with the command-line option and checking the relevant box during installation. I've also confirmed that it happens whether you add Python to the path or not. The latter is my use-case as I have multiple versions of Python installed and use the Python Launcher for Windows to select a version to run or virtualenv to build. Looking at the source, I suspect this feature was completely lost when the MSI build system was rewritten in commit https://github.com/python/cpython/commit/bb24087a2cbfb186b540cc71a74ec8c39c1ebe3a (formerly https://hg.python.org/cpython/rev/e7dbef447157) for issue #23260 which removed all references to SystemFolder or System64Folder -- messages: 289801 nosy: TBBle priority: normal severity: normal status: open title: Windows Python installers not installing DLL to System32/SysWOW64 versions: Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29844> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18125] Out-of-tree build cannot regenerate Makefile.pre
New submission from Paul TBBle Hampson: Noticed in Python 2.7 but a quick look in the repository suggests this is also true in Python 3 releases. The Makefile rule for Makefile.pre in Makefile.pre.in is: # Build the toplevel Makefile Makefile.pre: Makefile.pre.in config.status CONFIG_FILES=Makefile.pre CONFIG_HEADERS= $(SHELL) config.status $(MAKE) -f Makefile.pre Makefile However, when built out-of-tree, Makefile.pre is in the build directory, as as config.status, but Makefile.pre.in is in the source directory. So the rule should be # Build the toplevel Makefile Makefile.pre: $(srcdir)/Makefile.pre.in config.status CONFIG_FILES=Makefile.pre CONFIG_HEADERS= $(SHELL) config.status $(MAKE) -f Makefile.pre Makefile Note that the recipe doesn't change, as config.status internally knows where Makefile.pre.in is found, so it's just the rule dependency that's wrong. This bug results in No rule to create Makefile.pre.in if Makefile.pre is somehow newer than Makefile or Modules/config.c in the build tree. -- components: Build messages: 190525 nosy: TBBle priority: normal severity: normal status: open title: Out-of-tree build cannot regenerate Makefile.pre versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18125 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18125] Out-of-tree build cannot regenerate Makefile.pre
Changes by Paul TBBle Hampson paul.hamp...@pobox.com: -- type: - compile error ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18125 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18125] Out-of-tree build cannot regenerate Makefile.pre
Paul TBBle Hampson added the comment: Forgot to mention, this is the only occurrence of a *.in file in Makefile.pre.in that isn't prefixed with $(srcdir)/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18125 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3741] DISTUTILS_USE_SDK set causes msvc9compiler.py to raise an exception
New submission from Paul TBBle Hampson [EMAIL PROTECTED]: Basically, if DISTUTILS_USE_SDK is set in the environment and an extension is attempted to be built from within the Windows SDK shell (ie. MSSdk is set in the environment as well), msvc9compiler.py will raise an exception due to a reference to the undefined self.__paths in MSVCCompiler.find_exe class, called from MSVCCompiler.initialize. self.__paths is used both in MSVCCompiler.find_exe and further through MSVCCompiler.initialize, but only exists if the else branch of the DISTUTILS_USE_SDK if/else is taken. I've attached a patch which trivially fixes this by setting self.__paths to [] before the test for DISTUTILS_USE_SDK. However, the use of MSVCCompiler.find_exe in this test might be wrong. Short of raising an exception, MSVCCompiler.find_exe always returns what it is supplied if it can't find anything better. So testing the truth of this value is likely incorrect. (I assume that find_exe used to return a false value if the requested program could not be found on the path or in self.__paths[]...) If the find_exe is removed from the test, then the setting of self.__paths can be done inside the if branch, paralleling the else branch. -- components: Distutils files: msvc9compiler-windowssdk.diff keywords: patch messages: 72209 nosy: TBBle severity: normal status: open title: DISTUTILS_USE_SDK set causes msvc9compiler.py to raise an exception versions: Python 2.6 Added file: http://bugs.python.org/file11318/msvc9compiler-windowssdk.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3741] DISTUTILS_USE_SDK set causes msvc9compiler.py to raise an exception
Paul TBBle Hampson [EMAIL PROTECTED] added the comment: The line my patch adds was present originally, and lost when msvccompiler.py was duplicated into msvc9compiler.py in revision 59290. http://svn.python.org/view?rev=59290view=rev ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
