[issue1074] python3.0-config script does not run on py3k
New submission from Koen van de Sande: The python3.0-config script, installed into the py3k bin folder, does not run on Python 3.0a1, because of the syntax change in the "print" statement. Possibly there are other compatibility issues. -- components: None messages: 55538 nosy: koen severity: normal status: open title: python3.0-config script does not run on py3k versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1074> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3936] Faulty suppression of 'as' keyword warning
Koen van de Sande <[EMAIL PROTECTED]> added the comment: I was wondering why I didn't have any warnings in my code in 2.5, when it started failing with errors on import in 2.6. Now I know. -- nosy: +koen ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4013] Python 2.6 Doc/tools folder bigger than in 2.6rc2
New submission from Koen van de Sande <[EMAIL PROTECTED]>: The Doc/tools folder in the 2.6 distribution contains docutils, jinja, pygments, sphinx folders, which were not there in the 2.6rc2 .tar.bz2. Also, there is a roman.pyc in the Doc/tools folder. The difference in uncompressed size is about 9MB between 2.6 and 2.6rc2. The difference in compressed size is 1.5MB. Perhaps including a fully functional doc build environment is intentional? -- assignee: georg.brandl components: Documentation messages: 74156 nosy: georg.brandl, koen severity: normal status: open title: Python 2.6 Doc/tools folder bigger than in 2.6rc2 type: resource usage versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4013> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4014] Python-2.6-py2.6.egg-info contains Alpha reference
New submission from Koen van de Sande <[EMAIL PROTECTED]>: In file lib/python2.6/lib-dynload/Python-2.6-py2.6.egg-info, after a fresh installation of Python 2.6 there are two lines for Development status both Alpha and Mature: Platform: Many Classifier: Development Status :: 3 - Alpha Classifier: Development Status :: 6 - Mature Classifier: License :: OSI Approved :: Python Software Foundation License This is found in line 1839 of http://svn.python.org/view/python/tags/ r26/setup.py?rev=66716&view=markup -- components: None messages: 74157 nosy: koen severity: normal status: open title: Python-2.6-py2.6.egg-info contains Alpha reference versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4014> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4022] 2.6 dependent on c:\python26\ on windows
Koen van de Sande <[EMAIL PROTECTED]> added the comment: Have you tried restarting your machine after installing the Visual C++ runtime from Microsoft? These runtimes will sometimes only finish installing after a reboot. Also, putting them in System/System32 is not "allowed" by MSVCR90.dll, either it goes into your application folder (together with a .manifest file), or into the WinSXS folder. -- nosy: +koen ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4022> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch
Koen van de Sande added the comment: There should be no manifest embedded into wininst, because then the cases which Issue 4120 fixed (a CRT installed into a local folder, instead of system-wide, due to limited access rights), will 'break' again: the installer can then no longer work unless there is a system-wide installation of the CRT. Option #1, #2 and #3 all sound reasonable (and #2 is the current situation). I have some doubts about option #4: it is a very specific use case, and then the whole benefit of issue 4120 is lost, because stripping runtimes would have to be removed again. Why is putting a separate manifest file next to the DLL not an option? Combined with #3 (allow extension developer to disable embedding of manifests) a separate manifest can fix the problem. -- nosy: +koen ___ Python tracker <http://bugs.python.org/issue7833> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch
Koen van de Sande added the comment: Concerning the patch: what happens when the developer already added /MANIFEST:NO to the flags, and the code deduces that MSVCR9 is the only runtime, e.g. the case where /MANIFEST:NO is in the flags twice? Does the linker handle this OK, or does there need to be an additional check as to not have it twice? -- ___ Python tracker <http://bugs.python.org/issue7833> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Koen van de Sande <[EMAIL PROTECTED]> added the comment: In response to 74742: > This issue doesn't stop here, here's another situation: Python is compiled with MSVC9. A user has it and MSVC9 SP1 installed, which has a newer CRT version. If he builds site-packages, these files have an embedded manifest with another CRT version than the python interpreter itself. Importing these packages loads a second copy of a CRT into the processes memory, just like described above. This is not true. For MSVC9SP (VS2008) Microsoft decided that by default, it will still compile against the original CRT. Only by explicitly adding a compiler flag can you use the updated SP1 CRT (they did this because the 2005SP1 caused so much grief, which did automatically upgrade the CRT, and subsequently companies did not roll out SP1 to prevent the mixing of CRTs). So you can safely compile using SP1 installed, and you will at least still use the same CRT version. -- nosy: +koen ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Koen van de Sande <[EMAIL PROTECTED]> added the comment: The TCL85.dll introduces a subtlety (actually it is TK85.dll). The MSVCRT90 is not the only dependency that can be in the manifest. The Windows.CommonControls.6.0 is used by TK85.dll. So, also for all Python extensions which have additional dependencies beside MSVCRT90, the manifest should still be included. Situation: - .pyd only depends on MSVCRT90: no manifest needed (will fallback to Python 2.6's own manifest and to WinSXS or the installation in the main Python folder) - .pyd has more dependencies: manifest is needed. But, a wild idea, perhaps we could strip MSVCRT90 from the manifest? This is speculation, but perhaps the fallback to the manifest of Python26.exe will still work this way, and the runtimes will only need to be in a single place. Anyone know of an easy-to-build example of a Python extension with extra dependencies? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Koen van de Sande <[EMAIL PROTECTED]> added the comment: Instead of reverting the patch for Issue 2563, I propose to strip the VC90 runtimes from the manifest (this will preserve other dependencies needed). I checked this by editing tk85.dll and replacing the dependency there with white-space - the Windows Common Controls dependency still worked properly after this. I've attached a patch to strip the runtime from the manifest when building Python extensions (through search/replace). I think somehow the manifests of the .pyd's in DLLs should also be edited, because leaving them out will cause problems if this is done when building tk85.dll. Or perhaps only special care is needed if there ever is a .pyd with additional dependencies? All files with the .pyd extension do not rely on anything else. I don't know enough about the build process to suggest a change for this, except that the build config for the .dll files inside DLLs might also need to be changed. Added file: http://bugs.python.org/file11847/msvc9compiler_stripruntimes.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Koen van de Sande <[EMAIL PROTECTED]> added the comment: _CRT_NOFORCE_MANIFEST sounds nice, but I'm having some trouble getting it to work for Python extensions. I'm still having manifests generated...? Can you show me how to use it? It is an undocumented option. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Koen van de Sande <[EMAIL PROTECTED]> added the comment: OK, so the define is not going to work. For Python extensions built through distutils, the msvc9compiler_stripruntimes.diff patch will work: it will remove just the dependency on the VC90runtimes. It will leave other assembly dependencies if they are there. For the .pyd's and .dll's in the DLLs folder: I have opened them in a hex editor, and just by hand replaced the entry for the VC90runtimes in each file with spaces. I can confirm that this works, also for _tkinter, for which tk85.dll has an additional dependency on Windows Common Controls (though this one was available in my WinSXS). What would be the best way to integrate a search/replace operation like this in the Python build process? Is the manifest generated as a seperate file here first as well, or is it directly embedded? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Koen van de Sande <[EMAIL PROTECTED]> added the comment: Ah, I wasn't thinking it through. It is fine for all .pyd of course, because they don't have any extra dependencies. I was thinking of DLLs with extra dependencies (of which there is one, TK85.dll). There, leaving out the manifest will break it. But indeed, the patch is fine for .pyd building. My mistake! ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4710] [PATCH] zipfile.ZipFile does not extract directories properly
Koen van de Sande added the comment:
I'm no expert, but is it possible for ZIP files to have Windows-style
path seperators ('\') as well?
And is this new behavior desirable for existing code as well? It might
break existing applications, so perhaps a new extractrecursive()
function is more intuitive.
Finally, I've noticed that the patch does not add any tests to test for
the new/old behavior.
--
nosy: +koen
___
Python tracker
<http://bugs.python.org/issue4710>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Koen van de Sande added the comment: @johan: no it is not a symptom of the same problem. The problem you are having is that the executable which is embedding Python does not have a manifest. If you add a manifest with a dependency on the VC90 runtimes to the main executable, then it should work AFAIK. ___ Python tracker <http://bugs.python.org/issue4120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Koen van de Sande added the comment: Could msvc9compiler_stripruntimes.diff still be considered for inclusion in Python 2.6.3 (high priority?)? A lot of .pyd's of third-party extensions are getting dependencies on MSVCR90 added to the .pyd, which makes them not work if the runtimes are not installed into the WinSxS folder and/or when embedding into other applications. For example, PIL encountered this problem recently. In essence, all Windows Python extensions built using setup.py build_ext encounter this problem. What the patch does is edit the manifest file to remove only the dependency on Microsoft.VC90.CRT. -- ___ Python tracker <http://bugs.python.org/issue4120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Koen van de Sande added the comment: It probably won't make 2.6.3 as the final is just out. But can we have it for 2.6.4? Here's a link to the relevant discussion on ImageSIG: http:// mail.python.org/pipermail/image-sig/2009-October/005918.html Looking at my local extensions installed, Matplotlib has applied this patch, but PyGame and PIL have embedded manifests with dependencies on the runtime in their .pyd's. The patch now does a text search/replace on an XML file, if you think this is bad style I could rewrit it to use proper XML parsing and writing. -- ___ Python tracker <http://bugs.python.org/issue4120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Koen van de Sande added the comment: Thanks Christoph, those are two important fixes to the patch. I'm +1 on having this in the next 2.6 maintenance release. -- ___ Python tracker <http://bugs.python.org/issue4120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Koen van de Sande added the comment: > It may actually be enough to just place the Microsoft.VC90.CRT.manifest file into the Python folder (the one with python.exe and the CRT DLLs). I concur with what Christoph says, that is how the embedded installation works. However, the .pyd files are not in the Python main folder. And therefore they shouldn't have a manifest for the runtimes (because it will look in the current folder relative to the DLL/pyd), because then the runtimes of the main python.exe will be used (which can then be in the same folder as the 'embedded' MSVCR location). -- ___ Python tracker <http://bugs.python.org/issue4120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
Koen van de Sande added the comment: The MinGW breakage probably comes from the same "issue" as encountered in http://bugs.python.org/issue4120#msg80908 and #msg80909: the main application, which embeds Matplotlib, does not have a manifest for the MSVCR9 runtimes? That's a problem which should be addressed by adding a manifest in the main application (and manifests can also be separate files called app.exe.manifest if you do not want to embed it). -- ___ Python tracker <http://bugs.python.org/issue4120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5689] please support lzma compression as an extension and in the tarfile module
Koen van de Sande added the comment: The LZMA implementation from 7-zip has been released as public domain (since version 4.62 / Nov 2008) in the LZMA SDK: http://www.7-zip.org/ sdk.html So, there shouldn't be a license issue for Windows. I am not sure if there are already system-provided LZMA libraries on Linux at this time. -- nosy: +koen ___ Python tracker <http://bugs.python.org/issue5689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5689] please support lzma compression as an extension and in the tarfile module
Koen van de Sande added the comment: The XZ Utils website ( http://tukaani.org/xz/ ) states the following: "The most interesting parts of XZ Utils (e.g. liblzma) are in the public domain. You can do whatever you want with the public domain parts. Some parts of XZ Utils (e.g. build system and some utilities) are under different free software licenses such as GNU LGPLv2.1, GNU GPLv2, or GNU GPLv3." So, liblzma is not the problem. But the license of PylibLZMA is LGPL3. -- ___ Python tracker <http://bugs.python.org/issue5689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch
Koen van de Sande added the comment: issue8870 and issue8871 are not related to this one. There, the UAC elevation fails, here the issue is with the MS runtimes, elevation is working fine. -- ___ Python tracker <http://bugs.python.org/issue7833> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8870] --user-access-control=force produces invalid installer on Vista
Koen van de Sande added the comment: This is listed as a known limitation of the Ext2 FS driver. From http://www.fs-driver.org/relnotes.html : === Running programs on an Ext2/Ext3 volume on Windows Vista Currently it is not possible to start a program on Vista if UAC is enabled and the program's executable is stored on an Ex2/Ext3 volume. An "invalid parameter" message box appears, but the program does not start. UAC is the feature of Vista that prompts the user to elevate the user privileges to administrator level when necessary. UAC is enabled by default. It is not recommended to disable it. The problem is caused by Vista's internals: There is some code that compares whether the name of the file system type is one of the following: "NTFS", "FAT", "FAT32", "CDFS", "NPFS", "MSFS" or "UDF". If there is a match, it is one of Microsoft's file system types and a lot of code is skipped in the Multiple UNC Provider (MUP) implementation of Vista. If the file system type is a third-party type, for example "Ext2", some code runs in the MUP of Vista that always generates an ERROR_INVALID_PARAMETER error status code due to a bug of Vista. === So the bug is in that FS (or in Windows if you will). It is not something Python can fix. -- nosy: +koen ___ Python tracker <http://bugs.python.org/issue8870> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
