[issue12703] Improve error reporting for packaging.util.resolve_name

Éric Araujo added the comment: This is now obsolete. For a discussion about moving resolve_name to another part of the stdlib, see #12915. -- resolution: -> out of date stage: patch review -> committed/rejected status: open -> closed ___ Python tra

[issue12703] Improve error reporting for packaging.util.resolve_name

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue12703] Improve error reporting for packaging.util.resolve_name

Éric Araujo added the comment: BTW modules in the standard library all use the dotted notation AFAIK, not the colon notation, so I would strongly prefer avoiding the colon notation. -- ___ Python tracker

[issue12703] Improve error reporting for packaging.util.resolve_name

Éric Araujo added the comment: http://bugs.python.org/file25773/resolve_name.patch is a patch that cleans up the function; I’ll see if it can be used to solve our problems without having to follow my drastic find_object idea. -- ___ Python tracker

[issue12703] Improve error reporting for packaging.util.resolve_name

Éric Araujo added the comment: FYI, here is code that can handle arbitrary dotted names: . I haven’t checked if its error reporting has the problem we’re discussing in this report. An alternative would be to use colon nota

[issue12703] Improve error reporting for packaging.util.resolve_name

Éric Araujo added the comment: In the absence of feedback, I’m going to apply my find_object idea as described in my previous message. -- ___ Python tracker ___ ___

[issue12703] Improve error reporting for packaging.util.resolve_name

Éric Araujo added the comment: I’ve found a way to make sure error messages always bubble up *and* clean up the ugly code in resolve_name, but it’s a rather drastic one. The idea is to restrict the function to work only with names defined at the module level, not arbitrarily nested names. T

[issue12703] Improve error reporting for packaging.util.resolve_name

Éric Araujo added the comment: I have added tests and fixed one or two bugs in 1405df4a1535. I have another patch that checks that error messages are useful, with one exception: if you try to import a.b and b raises an ImportError, then the calling code will see an Attribute error. Right no

[issue12703] Improve error reporting for packaging.util.resolve_name

Éric Araujo added the comment: Thanks. I’ll add more tests and commit. (I also prefer to create modules in test methods instead of using another file, so that I can see right here what the module contains.) -- ___ Python tracker

[issue12703] Improve error reporting for packaging.util.resolve_name

Rémy HUBSCHER added the comment: Here is the patch for the test case. -- hgrepos: +84 Added file: http://bugs.python.org/file23428/test_util.patch ___ Python tracker ___ ___

[issue12703] Improve error reporting for packaging.util.resolve_name

Rémy HUBSCHER added the comment: Ok, I am working on it. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue12703] Improve error reporting for packaging.util.resolve_name

Éric Araujo added the comment: I would like to commit this. Tests are needed. Does someone want to write them? Please ask any question you might have, we’re here to help :) -- stage: needs patch -> test needed versions: +3rd party ___ Python trac

[issue12703] Improve error reporting for packaging.util.resolve_name

Rémy HUBSCHER added the comment: It is exactly what explained Alexis. The __import__ can failed in two case : - The module doesn't exist - There is a error in the module With the previous behaviour, even if the module exist, the message was that it doesn't exists. And it was then not fast

[issue12703] Improve error reporting for packaging.util.resolve_name

Éric Araujo added the comment: I’m confused about what the proposed change would actually do. Could you explain what behavior you want to change and how? -- ___ Python tracker ___

[issue12703] Improve error reporting for packaging.util.resolve_name

Alexis Metaireau added the comment: Thanks Rémy, About testing, I would go for modules with errors in it and check that when imported trough this function it does what it is supposed to do. IOW: 1. Create a test python module with errors in their definition (Throw an exception would do the

[issue12703] Improve error reporting for packaging.util.resolve_name

Rémy HUBSCHER added the comment: Actually it is not the same problem for `distutils.util.Distribution.get_command_class` my mistake. -- ___ Python tracker ___ _

[issue12703] Improve error reporting for packaging.util.resolve_name

Rémy HUBSCHER added the comment: Hello, I did the patch, but I have no idea of how to make a test for it. More over, I have seen a similar problem each time there is this code in the Python code (here in distutils.util.Distribution.get_command_class) : try: __impo

[issue12703] Improve error reporting for packaging.util.resolve_name

Changes by Éric Araujo : -- keywords: +easy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue12703] Improve error reporting for packaging.util.resolve_name

Éric Araujo added the comment: Thanks for the report. Would you have time to make a code+test patch for the CPython repo? distutils2 has moved there under the name packaging. -- assignee: tarek -> eric.araujo stage: -> needs patch title: Loading a module -> Improve error reporting f