[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters
Change by Craig Holmquist : -- nosy: +craigh ___ Python tracker <https://bugs.python.org/issue46006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32689] shutil.move raises AttributeError if first argument is a pathlib.Path object and destination is a directory
Craig Holmquist <craigh...@gmail.com> added the comment: In my test, the second call to path.absolute() is just returning the same result as the first call, which is what I would expect (as you say, the path object doesn't update automatically). However, your output shows it returning '/Users/e/Development/OSS/cpython/test2' instead of the (now broken) path from the first call. Maybe I'm missing something? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32689] shutil.move raises AttributeError if first argument is a pathlib.Path object and destination is a directory
New submission from Craig Holmquist <craigh...@gmail.com>:
>>> import os, pathlib, shutil
>>> os.mkdir('test1')
>>> os.mkdir('test2')
>>> path = pathlib.Path('test1')
>>> shutil.move(path, 'test2')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.6/shutil.py", line 540, in move
real_dst = os.path.join(dst, _basename(src))
File "/usr/lib/python3.6/shutil.py", line 504, in _basename
return os.path.basename(path.rstrip(sep))
AttributeError: 'PosixPath' object has no attribute 'rstrip'
--
components: Library (Lib)
messages: 310900
nosy: craigh
priority: normal
severity: normal
status: open
title: shutil.move raises AttributeError if first argument is a pathlib.Path
object and destination is a directory
type: behavior
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32689>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31658] xml.sax.parse won't accept path objects
New submission from Craig Holmquist <craigh...@gmail.com>:
>>> import xml.sax
>>> import pathlib
[...]
>>> xml.sax.parse(pathlib.Path('path/to/file'), handler)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.6/xml/sax/__init__.py", line 33, in parse
parser.parse(source)
File "/usr/lib/python3.6/xml/sax/expatreader.py", line 105, in parse
source = saxutils.prepare_input_source(source)
File "/usr/lib/python3.6/xml/sax/saxutils.py", line 355, in
prepare_input_source
if source.getCharacterStream() is None and source.getByteStream() is None:
AttributeError: 'PosixPath' object has no attribute 'getCharacterStream'
--
components: Library (Lib), XML
messages: 303490
nosy: craigh
priority: normal
severity: normal
status: open
title: xml.sax.parse won't accept path objects
type: behavior
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31658>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23407] os.walk always follows Windows junctions
Changes by Craig Holmquist <craigh...@gmail.com>: Added file: http://bugs.python.org/file46718/issue23407-5.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29248] os.readlink fails on Windows
Craig Holmquist added the comment: New patch with test. I'm not sure if C:\Users\All Users and C:\ProgramData exist with those names on non-English installations of Windows. I set the test to skip if they aren't found. -- nosy: +craigh Added file: http://bugs.python.org/file46293/issue29248-2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29248> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23407] os.walk always follows Windows junctions
Craig Holmquist added the comment: New patch with spaces instead of tabs -- Added file: http://bugs.python.org/file46291/issue23407-4.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29248] os.readlink fails on Windows
Changes by Craig Holmquist <craigh...@gmail.com>: -- keywords: +patch Added file: http://bugs.python.org/file46290/issue29248.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29248> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23407] os.walk always follows Windows junctions
Craig Holmquist added the comment: Here's a new patch: now, _Py_attribute_data_to_stat and Py_DeleteFileW will just use the IsReparseTagNameSurrogate macro to determine if the file is a link, so os.walk etc. will know not to follow them. os.readlink, however, will only work with junctions and symbolic links; otherwise it will raise ValueError with "unsupported reparse tag". This way, there's a basic level of support for all name-surrogate tags, but os.readlink only works with the ones whose internal structure is (semi-) documented. -- Added file: http://bugs.python.org/file46289/issue23407-3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23407] os.walk always follows Windows junctions
Craig Holmquist added the comment: FWIW, the only name-surrogate tags in the user-mode SDK headers (specifically winnt.h) are IO_REPARSE_TAG_MOUNT_POINT and IO_REPARSE_TAG_SYMLINK, as of at least the Windows 8.1 SDK. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23407] os.walk always follows Windows junctions
Craig Holmquist added the comment: Can you point me toward any documentation on the additional tags you want to support? Searching for IO_REPARSE_TAG_IIS_CACHE mostly seems to yield header files that define it (and nothing at all on MSDN), and the non-Microsoft tags just yield a few results each. (For comparison, the junction and symbolic link tags yield 10K+ results each.) Junctions are created with each user's home directory so they exist on every Windows system, even if the user never explicitly creates them. The additional tags seem like they're far less common and much less well-documented. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23407] os.walk always follows Windows junctions
Craig Holmquist added the comment: Updated patch with changes to Win32JunctionTests. -- Added file: http://bugs.python.org/file44824/issue23407-2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23407] os.walk always follows Windows junctions
Craig Holmquist added the comment: Actually, it looks like there is already a way to create junctions and a test for them in test_os. However, it includes this line: # Junctions are not recognized as links. self.assertFalse(os.path.islink(self.junction)) That suggests the old behavior is intentional--does anyone know why? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23407] os.walk always follows Windows junctions
Craig Holmquist added the comment: The attached patch changes _Py_attribute_data_to_stat to set S_IFLNK for both symlinks and junctions, and changes win_readlink to return the target path for junctions (IO_REPARSE_TAG_MOUNT_POINT) as well as symlinks. I'm not sure what to do as far as adding a test--either Python needs a way to create junctions or the test needs to rely on the ones Windows creates by default. Incidentally, the existing win_readlink doesn't always work correctly with symbolic links, either (this is from 3.5.2): >>> import os >>> os.readlink(r'C:\Users\All Users') '\x00\x00f\x00\u0201\x00\x02\x00\x00\x00f\x00\x00\x00' The problem is that PrintNameOffset is an offset in bytes, so it needs to be divided by sizeof(WCHAR) if you're going to add it to a WCHAR pointer (https://msdn.microsoft.com/en-us/library/windows/hardware/ff552012(v=vs.85).aspx). Some links still seem to work correctly because PrintNameOffset is 0. The attached patch fixes this problem also--I wasn't sure if I should open a separate issue for it. -- keywords: +patch Added file: http://bugs.python.org/file44823/issue23407.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23779] imaplib authenticate raises TypeError if authenticator tries to abort
Craig Holmquist added the comment: Okay, I attached another patch. The new version of the test returns success if the client's response is anything other than the abort line (*\r\n). It fails with the current version of imaplib, fails if I change _Authenticator.process to output a byte-string besides *, and succeeds with the change in the patch. -- Added file: http://bugs.python.org/file38768/imap_auth3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23779 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23779] imaplib authenticate raises TypeError if authenticator tries to abort
Craig Holmquist added the comment: New patch is attached. -- Added file: http://bugs.python.org/file38749/imap_auth2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23779 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23779] imaplib authenticate raises TypeError if authenticator tries to abort
New submission from Craig Holmquist:
If the authenticator object passed to the IMAP authenticate method tries to
abort the handshake by returning None, TypeError is raised instead of sending
the * line to the server.
import imaplib
imap = imaplib.IMAP4_SSL('imap.gmail.com')
imap.authenticate(b'PLAIN', lambda x: None)
Traceback (most recent call last):
File pyshell#5, line 1, in module
imap.authenticate(b'PLAIN', lambda x: None)
File C:\Python34\lib\imaplib.py, line 380, in authenticate
typ, dat = self._simple_command('AUTHENTICATE', mech)
File C:\Python34\lib\imaplib.py, line 1133, in _simple_command
return self._command_complete(name, self._command(name, *args))
File C:\Python34\lib\imaplib.py, line 940, in _command
self.send(literal)
File C:\Python34\lib\imaplib.py, line 276, in send
self.sock.sendall(data)
File C:\Python34\lib\ssl.py, line 723, in sendall
v = self.send(data[count:])
File C:\Python34\lib\ssl.py, line 684, in send
v = self._sslobj.write(data)
TypeError: 'str' does not support the buffer interface
The problem is that _Authenticator.process returns a string instead of bytes in
this case.
--
components: Library (Lib)
files: imap_auth.patch
keywords: patch
messages: 239283
nosy: craigh
priority: normal
severity: normal
status: open
title: imaplib authenticate raises TypeError if authenticator tries to abort
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38694/imap_auth.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23779
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23486] Enum comparisons are 20x slower than comparing equivalent ints
New submission from Craig Holmquist: Running the attached test script: $ time python test.py enum real0m6.546s user0m6.530s sys 0m0.007s $ time python test.py int real0m0.384s user0m0.377s sys 0m0.000s I encountered this with a script that yielded a sequence of objects (potentially a few hundred thousand of them) and categorized them with instances of an Enum subclass. The consumer of that iteration processes each object with a switch-case-like comparison of the category, checking it sequentially against each instance of the Enum. This seems like a fairly common use case. From cProfile it looks like EnumMeta.__getattr__ and _is_dunder are the main bottlenecks: [...] 7/10.0000.0000.0000.000 abc.py:194(__subclasscheck__) 10.0000.0000.0010.001 enum.py:1(module) 30.0000.0000.0000.000 enum.py:132(genexpr) 2210.9880.0000.9880.000 enum.py:16(_is_dunder) 190.0000.0000.0000.000 enum.py:24(_is_sunder) 2021.8250.0002.8130.000 enum.py:241(__getattr__) 170.0000.0000.0000.000 enum.py:282(__setattr__) 30.0000.0000.0000.000 enum.py:342(_get_mixins_) 30.0000.0000.0000.000 enum.py:387(_find_new_) [...] -- components: Library (Lib) files: test.py messages: 236234 nosy: craigh priority: normal severity: normal status: open title: Enum comparisons are 20x slower than comparing equivalent ints type: performance versions: Python 3.4 Added file: http://bugs.python.org/file38177/test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23486 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23486] Enum comparisons are 20x slower than comparing equivalent ints
Craig Holmquist added the comment: I may not have been clear before. What I mean is, code like this: for obj in get_objects(): if obj.category == Cat.cat1: #do something elif obj.category == Cat.cat2: #do something else elif obj.category == Cat.cat3 or obj.category == Cat.cat4: #... obj.category is already an instance of Cat, in other words. The consumer is using it to determine what to do with each obj. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23486 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23486] Enum comparisons are 20x slower than comparing equivalent ints
Craig Holmquist added the comment: It seems like performance is drastically improved by doing this: class Category(Enum): tiny = 1 medium = 2 large = 3 tiny = Category.tiny medium = Category.medium In other words, resolving Category.tiny and Category.medium is what's slow. The comparison itself is very fast. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23486 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23407] os.walk always follows Windows junctions
New submission from Craig Holmquist: os.walk follows Windows junctions even if followlinks is False: import os appdata = os.environ['LOCALAPPDATA'] for root, dirs, files in os.walk(appdata, followlinks=False): ... print(root) C:\Users\Test\AppData\Local C:\Users\Test\AppData\Local\Apple C:\Users\Test\AppData\Local\Apple\Apple Software Update C:\Users\Test\AppData\Local\Apple Computer C:\Users\Test\AppData\Local\Apple Computer\iTunes C:\Users\Test\AppData\Local\Application Data C:\Users\Test\AppData\Local\Application Data\Apple C:\Users\Test\AppData\Local\Application Data\Apple\Apple Software Update C:\Users\Test\AppData\Local\Application Data\Apple Computer C:\Users\Test\AppData\Local\Application Data\Apple Computer\iTunes C:\Users\Test\AppData\Local\Application Data\Application Data C:\Users\Test\AppData\Local\Application Data\Application Data\Apple C:\Users\Test\AppData\Local\Application Data\Application Data\Apple\Apple Software Update C:\Users\Test\AppData\Local\Application Data\Application Data\Apple Computer C:\Users\Test\AppData\Local\Application Data\Application Data\Apple Computer\iTunes C:\Users\Test\AppData\Local\Application Data\Application Data\Application Data C:\Users\Test\AppData\Local\Application Data\Application Data\Application Data\Apple C:\Users\Test\AppData\Local\Application Data\Application Data\Application Data\Apple\Apple Software Update C:\Users\Test\AppData\Local\Application Data\Application Data\Application Data\Apple Computer C:\Users\Test\AppData\Local\Application Data\Application Data\Application Data\Apple Computer\iTunes C:\Users\Test\AppData\Local\Application Data\Application Data\Application Data\Application Data [...] For directory symbolic links, os.walk seems to have the correct behavior. However, Windows 7 (at least) employs junctions instead of symlinks in situations like the default user profile layout, i.e. the Application Data junction shown above. I also noticed that, for junctions, os.path.islink returns False but os.stat and os.lstat return different results. -- components: Library (Lib) messages: 235531 nosy: craigh priority: normal severity: normal status: open title: os.walk always follows Windows junctions type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23407 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4631] urlopen returns extra, spurious bytes
Changes by Craig Holmquist craigh...@gmail.com: -- nosy: +craigh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4631 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4566] 2.6.1 breaks many applications that embed Python on Windows
Craig Holmquist craigh...@gmail.com added the comment: I haven't been able to try this patch myself yet, but I see a potential problem: the cookie variable is declared as a DWORD, while ActivateActCtx expects a ULONG_PTR. DWORD and ULONG_PTR are only the same thing in 32-bit Windows. Also, where are you seeing that these SxS functions are Vista or later? My XP kernel32.dll has all of them. MSDN says they're XP or Vista. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4566 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4566] 2.6.1 breaks many applications that embed Python on Windows
Craig Holmquist craigh...@gmail.com added the comment: The patch works fine on my system (32-bit XP). Also I verified in Process Explorer that there's only one instance of msvcr90.dll loaded. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4566 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4566] 2.6.1 breaks many applications that embed Python on Windows
Craig Holmquist craigh...@gmail.com added the comment: Here's an option, though unfortunately not a trivial one: use a private build of the C runtime. The Windows version of Firefox does this (mozcrt19.dll). The private CRT build doesn't use SxS in any way, so it gets around this issue, as well as other issues like not allowing for me installs on Vista (#4018). For me to build the CRT from the source included with Visual Studio 2008 took some tweaking - apparently having the CRT source build properly out of the box wasn't a priority for MS (the Mozilla CRT seems to be built from the VS2005 source; perhaps that version is more cooperative). It does yield a CRT that links like an ordinary DLL, but the fact that it can't be built without modifications is a major drawback to this solution. Also, I'd assume that the CRT source isn't included in the Express version (and possibly other ones), so that's a downside, too. As far as Python itself, the project configurations would have to be changed to define _CRT_NOFORCE_MANIFEST, suppress the default linking to the stock CRT (/NODEFAULTLIB:msvcrt.lib), and link to the import library for the private CRT. I might try to create an experimental solution config for this. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4566 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4566] 2.6.1 breaks many applications that embed Python on Windows
Craig Holmquist craigh...@gmail.com added the comment: test.c's error is can't find the DLL - this will be as we attempt to load Python's DLL - but this isn't the same as the original error, which is DLL init routine failed. To repro the initial error, I suspect you will want to put the full assembly next to test.exe - that will allow python.dll to load - then test.c should call PyExec_EvalString(import socket\n) - it is at *that* point the error we care about is likely to be thrown. The test program isn't having a problem loading python26.dll - it gets to an interpreter prompt and it can execute simple Python statements. It doesn't throw ImportError until the user types in import socket. Further, I can see in Process Explorer that python26.dll is loaded in the running testpy.exe process. I apologize if my initial description wasn't clear on that point. I do see the error codes are different (between testpy.c and mod_python), but both are triggered by trying to load _socket.pyd. Nonetheless: if I copy the CRT assembly into the same folder as testpy.exe, I get a popup dialog when I try to import socket, saying Runtime Error! and R6034; An application has made an attempt to load the C library incorrectly.. When I click OK in that dialog, I get this error in the console running testpy.exe: ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed. (If the assembly is not in the folder, there is no popup dialog at all.) So it does indeed change the error code received. Also, I see now that I made a mistake in reporting the error code from the Apache log. The actual behavior is this: * Ordinary, the ImportError is: ImportError: DLL load failed: The specified module could not be found. * However, if I put the CRT assembly in the same folder as _socket.pyd: ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed. and I received the same popup dialog as above. Putting the CRT assembly in the Apache bin folder or Apache modules folder still gives the first error (module could not be found). I apologize for the confusion; when I first experienced this problem I tried to fix it by experimenting with putting the manifest in various folders and I wasn't paying close enough attention to what error was given when. To summarize: testpy.exe with CRT assembly in testpy.exe folder: init routine failed and popup. testpy.exe with CRT assembly in _socket.pyd folder: init routine failed and popup. testpy.exe otherwise: module could not be found Apache with CRT assembly in _socket.pyd folder: init routine failed and popup. Apache otherwise: module could not be found ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4566 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4566] 2.6.1 breaks many applications that embed Python on Windows
Craig Holmquist craigh...@gmail.com added the comment: I took a look at this with the debugger, as Mark recommended. The CRT's DLLMain is called _CRTDLL_INIT, that in turn calls __CRTDLL_INIT. __CRTDLL_INIT calls another function, _check_manifest. _check_manifest calls an SxS function called FindActCtxSectionString. It's looking for a string called msvcr90.dll in the ACTIVATION_CONTEXT_SECTION_DLL_REDIRECTION section of the process's activation context (activation contexts are data structures used by SxS). That call fails (_check_manifest doesn't call GetLastError or anything, it just returns FALSE right there). There's a comment there that says: /* no activation context used to load CRT DLL, means no manifest present in the process */ What's bizarre is that python26.dll successfully loaded msvcr90.dll (the global one from WinSxS), so it must have passed _check_manifest. It seems like the activation context consists of the DLL's manifest (_socket.pyd's in this case) and the exe's manifest, but no other ones, regardless of what other libraries have been loaded. The documentation doesn't seem to explain the interaction between manifests in different modules. It's also annoying that this restriction (the _check_manifest call) is completely artificial. I don't know if any of this information is useful (I'm only superficially familiar with activation contexts and the functions to manipulate them). The code is all in crtlib.c (in the CRT source) if someone else wants to take a look. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4566 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4566] 2.6.1 breaks many applications that embed Python on Windows
Craig Holmquist [EMAIL PROTECTED] added the comment: I don't quite understand this issue yet. python26.dll is linked with a manifest. Isn't that good enough? Apparently not, at least in my testing. It seems that if a DLL is loaded, Windows will try to resolve its dependencies by looking at that DLL's own manifest; if that fails, Windows will try to resolve them by looking at the EXE's manifest. It won't check other DLLs. From the loader's perspective, it seems like there's no tree of DLLs, it's just EXE loads DLL, EXE loads DLL, even if the loading code is actually in one of the DLLs. I guess I'm more concerned about applications like Apache that only use Python through an external module or plugin; there's no reason the Apache developers would be expected to make this kind of change with the manifests and everything, much less any commercial, closed-source app (say, an IDE or editor that has plugins for several scripting languages). Also, the manifest trick I described as a workaround was only as simple as it was in this case because httpd.exe didn't have any manifest at all; if it already had an internal manifest, working-around this would have been much more gruesome. I understand, though, the value of xcopy deployment, and I realize that having some means of doing that is better than none at all. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4566 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4566] 2.6.1 breaks many applications that embed Python on Windows
New submission from Craig Holmquist [EMAIL PROTECTED]: Applications on Windows that don't link to the MSVCR90.DLL via a manifest are broken with Python 2.6.1. This includes apps that link with the C library statically and apps that link with other versions of it. These applications worked fine with Python 2.6. To test this, I created a simple application that did nothing but call Py_Main (compiled with VS2008). When that app links with the C library statically, attempting to import the socket module gives this error: Traceback (most recent call last): File stdin, line 1, in module File C:\Python26\lib\socket.py, line 46, in module import _socket ImportError: DLL load failed: The specified module could not be found. When that app links with the C library dynamically, it works properly. In particular, this issue breaks mod_python. From the Apache error log: [Sat Dec 06 00:49:21 2008] [error] make_obcallback: could not import mod_python.apache.\n Traceback (most recent call last): File C:\Python26\lib\site-packages\mod_python\apache.py, line 29, in module import cgi File C:\Python26\Lib\cgi.py, line 40, in module import urllib File C:\Python26\Lib\urllib.py, line 26, in module import socket File C:\Python26\lib\socket.py, line 46, in module import _socket ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed. I'm guessing this is a side-effect of the fix for #4120. Since modules like _socket.pyd don't have manifests that tell Windows where to find the side-by-side assembly to load, and the application loading _socket.pyd doesn't have it in its manifest either, Windows has no clue where to find MSVCR90.dll. Something I discovered (by accident) is that, if there's an external manifest in the same folder as the hosting application (ie, testpy.exe.manifest) that points to the C runtime, it fixes the problem, even if the host app links statically to the C runtime. I don't recall off-hand whether these external manifests take precedence over the internal ones, but in this case it seems to provide enough information to Windows that it can resolve the dependency. -- components: Windows messages: 77133 nosy: craigh severity: normal status: open title: 2.6.1 breaks many applications that embed Python on Windows type: behavior versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4566 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4566] 2.6.1 breaks many applications that embed Python on Windows
Changes by Craig Holmquist [EMAIL PROTECTED]: Added file: http://bugs.python.org/file12249/testpy.c ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4566 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4566] 2.6.1 breaks many applications that embed Python on Windows
Craig Holmquist [EMAIL PROTECTED] added the comment: I've attached the test program I was using. The commands I used to compile it are: cl /MT /c /IC:\Python26\include testpy.c link /LIBPATH:C:\Python26\libs testpy.obj ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4566 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4566] 2.6.1 breaks many applications that embed Python on Windows
Craig Holmquist [EMAIL PROTECTED] added the comment: I've attached a manifest file that references the C runtime; adding this file to the Apache bin folder seems to workaround this issue. Added file: http://bugs.python.org/file12250/httpd.exe.manifest ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4566 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4566] 2.6.1 breaks many applications that embed Python on Windows
Craig Holmquist [EMAIL PROTECTED] added the comment: I understand the rationale behind #4120, but it seems like it only helps a narrow set of applications, namely applications that link dynamically with the same version of MSVCR90 as Python and that bundle the MSVCR90 DLL and that can't install the VS2008 redist. In 2.6.1 those apps don't have to install the VS2008 redist, but every other app needs to either bundle the runtime DLLs (as a private assembly) or use the manifest workaround I described above, even if the VS2008 redist is installed on the system. The 2.6.0 behavior - requiring the VS2008 redist to be installed - is hardly perfect (to put it mildly), but in my opinion it's more obvious and straightforward, and more consistent with the behavior of other Windows software. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4566 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4043] Attempting to import deprecated modules in IDLE raises TypeError
New submission from Craig Holmquist [EMAIL PROTECTED]: In Python 2.6, attempting to import depecated modules in IDLE raises a TypeError exception. I verified this with sets, mimify, and MimeWriter. Here's the output for sets: import sets Traceback (most recent call last): File pyshell#2, line 1, in module import sets File C:\Python26\Lib\sets.py, line 85, in module stacklevel=2) File C:\Python26\Lib\warnings.py, line 29, in _show_warning file.write(formatwarning(message, category, filename, lineno, line)) TypeError: idle_formatwarning_subproc() takes exactly 4 arguments (5 given) The other modules give a similar trace. Normally, I wouldn't consider this a serious issue, but there are some major packages out there that still use deprecated modules such as these. For example, MySQLdb 1.2.2 and SQLAlchemy 4.7p1 import the sets module so they can't be used at all in IDLE. -- components: IDLE messages: 74324 nosy: craigh severity: normal status: open title: Attempting to import deprecated modules in IDLE raises TypeError type: behavior versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4043 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4043] Warnings in IDLE raise TypeError (such as attempting to import deprecated modules)
Craig Holmquist [EMAIL PROTECTED] added the comment:
Actually, it looks like ANY warning will raise this error in IDLE. For
example:
import warnings
warnings.warn('blah blah')
Traceback (most recent call last):
File pyshell#5, line 1, in module
warnings.warn('blah blah')
File C:\Python26\Lib\warnings.py, line 29, in _show_warning
file.write(formatwarning(message, category, filename, lineno, line))
TypeError: idle_formatwarning_subproc() takes exactly 4 arguments (5 given)
--
title: Attempting to import deprecated modules in IDLE raises TypeError -
Warnings in IDLE raise TypeError (such as attempting to import deprecated
modules)
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4043
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4043] Warnings in IDLE raise TypeError (such as attempting to import deprecated modules)
Craig Holmquist [EMAIL PROTECTED] added the comment: I should have checked this more carefully, but apparently you can still use the imported module after the exception. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4043 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4043] Warnings in IDLE raise TypeError (such as attempting to import deprecated modules)
Craig Holmquist [EMAIL PROTECTED] added the comment: Okay, I think I've got it now: 1. If you import sets, it raises TypeError. However, if you import it a second time, it seems to work properly. 2. Trying to import a module that relies on the deprecated module (ie, sqlalchemy) fails no matter how many times it's imported. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4043 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4019] 2.6 (final) uses old icons in Start Menu
New submission from Craig Holmquist [EMAIL PROTECTED]: The Start Menu icons created by the Python 2.6 installer use the old icons (the green snake, 4-bit color) instead of the new ones (blue and yellow snake, 24-bit color). This was observed on Windows XP. An installation of 2.5.2 on the same machine uses the new icons. -- components: Installation messages: 74171 nosy: craigneuro severity: normal status: open title: 2.6 (final) uses old icons in Start Menu type: behavior versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4019 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3215] Can't import sqlite3 in Python 2.6b1
New submission from Craig Holmquist [EMAIL PROTECTED]: This is observed on Windows XP; I don't know if it affects other platforms. Trying to import sqlite3 gives this error: import sqlite3 Traceback (most recent call last): File pyshell#1, line 1, in module import sqlite3 File C:\Python26\Lib\sqlite3\__init__.py, line 24, in module from dbapi2 import * File C:\Python26\lib\sqlite3\dbapi2.py, line 27, in module from _sqlite3 import * ImportError: DLL load failed: The specified module could not be found. A look at the dependencies for _sqlite3.pyd shows that it's trying to link to a file called sqlite3.pyd, which doesn't exist. Renaming sqlite3.dll to sqlite3.pyd doesn't work either, because then import sqlite3 causes Python to try to import that file as a Python module (instead of C:\Python26\Lib\sqlite3\__init__.py). In Python 2.5.2, the _sqlite3.pyd module correctly links to sqlite3.dll. If there's already an issue regarding this I couldn't find it. -- components: Extension Modules, Windows messages: 68827 nosy: craigneuro severity: normal status: open title: Can't import sqlite3 in Python 2.6b1 type: behavior versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3215 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2840] Expat parser locks XML source file if ContentHandler raises an exception
New submission from Craig Holmquist [EMAIL PROTECTED]: This was observed in Python 2.5.2 on Windows XP. Run this code in IDLE: import xml.sax from xml.sax.handler import ContentHandler class C(ContentHandler): def startElement(self, name, attrs): assert False xml.sax.parse(xml_path, C()) Where xml_path points to a well-formed XML file. This will raise an AssertionError. Then, attempt to modify or delete the XML file that was specified; it's still locked by the Python process. Deleting the ContentHandler does not unlock it. There doesn't seem any way to unlock it aside from terminating the Python process. If the ContentHandler doesn't raise an exception or error, the file is unlocked properly. -- components: XML messages: 66754 nosy: craigneuro severity: normal status: open title: Expat parser locks XML source file if ContentHandler raises an exception type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2840 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
