Repository navigation
Output .pyd name in error message of ImportError when DLL load fails #55063
Description
| BPO | 10854 |
|---|---|
| Nosy | @loewis, @birkenfeld, @amauryfa, @ncoghlan, @kristjanvalur, @briancurtin, @ericsnowcurrently, @eryksun, @iritkatriel |
| Dependencies | |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/briancurtin'
closed_at = <Date 2020-11-17.01:22:59.623>
created_at = <Date 2011-01-07.15:48:43.761>
labels = ['extension-modules', 'type-feature', '3.9', '3.10']
title = 'Output .pyd name in error message of ImportError when DLL load fails'
updated_at = <Date 2020-11-17.01:22:59.619>
user = 'https://bugs.python.org/techtonik'bugs.python.org fields:
activity = <Date 2020-11-17.01:22:59.619>
actor = 'eryksun'
assignee = 'brian.curtin'
closed = True
closed_date = <Date 2020-11-17.01:22:59.623>
closer = 'eryksun'
components = ['Extension Modules']
creation = <Date 2011-01-07.15:48:43.761>
creator = 'techtonik'
dependencies = ['1559549']
files = ['22768', '26476']
hgrepos = []
issue_num = 10854
keywords = ['patch']
message_count = 25.0
messages = ['125649', '125651', '125652', '125653', '125663', '125665', '125668', '125682', '125727', '125765', '125768', '126279', '126281', '126283', '141205', '141209', '147439', '158399', '162376', '162616', '166124', '166143', '166179', '381184', '381202']
nosy_count = 13.0
nosy_names = ['loewis', 'georg.brandl', 'amaury.forgeotdarc', 'ncoghlan', 'kristjan.jonsson', 'techtonik', 'brian.curtin', 'cgohlke', 'python-dev', 'eric.snow', 'piotr.dobrogost', 'eryksun', 'iritkatriel']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue10854'
versions = ['Python 3.9', 'Python 3.10']
Activity
birkenfeld commentedon Jan 8, 2011
No idea what a BSDL is, but a developer is definitely entitled to close a bug without resorting to a "majority" decision (what is that, anyway? should we hold monthly parliament over bugs?).
You're of course free to reopen with a different request, as you did, and I also think it'd be useful to have the failed module name in the message.
ncoghlan commentedon Jan 14, 2011
As Martin says, we aren't inclined to implement or maintain the equivalent of depends.exe in order to provide a slightly better error message.
If anyone wants to reopen this issue, provide a patch. Otherwise devs are just going to close it again.
Optionally, campaign for a fix on python-list and see if you can persuade someone *else* to provide a patch.
You could even go to the source of the problem and ask *Microsoft* to provide a better error message.
ncoghlan commentedon Jan 14, 2011
Sorry, I missed that the request had changed to just the .pyd name. That at least is useful, since you then know where to start with depends.exe. It should be fairly straightforward to implement as well.
Adjusted issue title accordingly.
[-]Output DLL name in error message of ImportError when DLL is missing[/-][+]Output .pyd name in error message of ImportError when DLL load fails[/+]techtonik commentedon Jan 14, 2011
Great. Thanks!
briancurtin commentedon Jul 27, 2011
How about something like this?
ImportError moves from being a "simple" exception to a "complex" one, then adds a "name" and "path" attribute. In dynload_win.c where we try (and fail) to load C extensions, the name and path are set on the ImportError. The test simply creates a file following the C extension name format and checks that the attributes end up being correct upon ImportError.
Jazzing up the ImportErrors elsewhere in the code might be useful after this, but I'll handle that in another issue if this gains traction.
ncoghlan commentedon Jul 27, 2011
See also bpo-1559549, which similarly adds attribute support to ImportError and covers some of the issues with using positional arguments to do so.
Extending that approach to a path keyword argument as well should work nicely.
briancurtin commentedon Nov 11, 2011
Marked bpo-1559549 as a dependency. I combine the patch in this issue with the one over there.
python-dev commentedon Apr 16, 2012
New changeset f341b99bb370 by Brian Curtin in branch 'default':
Fix bpo-10854. Make use of the new path and name attributes on ImportError
http://hg.python.org/cpython/rev/f341b99bb370
kristjanvalur commentedon Jun 5, 2012
repr() or str() of ImportError doesn't include the 'name' or 'path' members. It would be useful to have them added to the repr if present.
kristjanvalur commentedon Jun 11, 2012
Brian, reopening this since the original issue isn't addressed: The "path" and "module" attributes aren't part of the error "repr"
kristjanvalur commentedon Jul 22, 2012
An example patch that aims to put the "name" and "path" in str() and repr() representations of ImportError.
Output when _socket.pyd is not found:
>>> import socket Traceback (most recent call last): File "<stdin>", line 1, in <module> File "D:\pydev\hg\cpython3\lib\socket.py", line 47, in <module> import _socket ImportError: No module named '_socket', _socket, >>> sys.last_value <ImportError "No module named '_socket'", '_socket', None> >>>amauryfa commentedon Jul 22, 2012
How it the new message better than "ImportError: No module named '_socket'"?
kristjanvalur commentedon Jul 22, 2012
Ok, the demo demo I added sucks, because I didn't demo the original problem (.pyd found but could not be loaded), but the point is, it displays the "name" and "path" attributes. They can be set, for example, if the module is found but cannot be loaded for some reason.
That's the point of this issue. The fix added a "name" and "path" attributes, but they were never actually _output_ when such an error occurred.
iritkatriel commentedon Nov 16, 2020
The patch adding 'name' and 'path' to the ImportError str/repr was not merged yet.
eryksun commentedon Nov 17, 2020
It's up to whatever code raises an ImportError to determine how the name and path should be included in the error message. In Windows, the DLL name was added to the exception message in 3.8. So I'm closing this issue again, with regard to its final scope.
With regard to its original scope, the reason for closing is "wont fix". There are no plans to extend the import error of an extension module in Windows to include the missing DLL dependency that caused the import to fail. There are tools such as the "DLL Diagnostics" package on PyPI that implement a proper trace by parsing loader snaps, and at the very least there are tools such as dumpbin.exe (or link.exe /dump) to manually list the direct dependencies of a DLL.