I patched it for redbarrel but there is the same bug on distutils2.

This patch allow to see the error raised when loading the module instead of saying that the module does not exists.

https://bitbucket.org/tarek/redbarrel/changeset/2cf6d7e32081#chg-redbarrel/util.py

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.

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:
                __import__ (module_name)
                module = sys.modules[module_name]
            except ImportError:
                continue

            try:
                klass = getattr(module, klass_name)
            except AttributeError:
                raise DistutilsModuleError(
                      "invalid command '%s' (no class '%s' in module '%s')"
                      % (command, klass_name, module_name))


Maybe it could be better to have a function in cpython to do that ?

Actually it is not the same problem for `distutils.util.Distribution.get_command_class` my mistake.

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 trick)
2a. Try to load this python module, check that the exception is the one thrown in the module
2.b Check that loading a non existing modules still tell us that the module doesn't exist
2.c Check that importing something existing works, trough this function. 

Hope I'm clear enough, thanks again,
Alexis

I’m confused about what the proposed change would actually do.  Could you explain what behavior you want to change and how?

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 forward to guess where was the error.

With this new behaviour, if there is an __import__ error and the module file actually exists, then we raise the real exception problem from the module that we try to import.

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 :)

Ok, I am working on it.

Here is the patch for the test case.

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.)

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 now I don’t see how we can avoid that; checking the existence of files like your patch proposes is not possible, as Python modules do not come from files.

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.  That way, the code is much easier to write: split on '.', pop the last element and keep it for later, __import__ the rest of the name and look it up in sys.modules.  One consequence is that you can’t use package.module.SomeClass.NestedClass for a command, nor module.SomeClass.staticmethod as setup hook; to be pragmatic, I’m not sure that was really useful, and in any case you just have to do a module-level alias (“x = SomeClass.staticmethod”) to make it work.

To reflect the fact that the function has restrictions, I renamed it from the generic “resolve_name” to the vague “find_object”; vague is better because it makes less promises and should cause developers using to look at the docs or docstring.

In short, it’s a clear improvement code-wise that should not impact most of the users, and I like it a lot.

In the absence of feedback, I’m going to apply my find_object idea as described in my previous message.

FYI, here is code that can handle arbitrary dotted names: <http://svn.eby-sarna.com/Importing/peak/util/imports.py?view=markup>.  I haven’t checked if its error reporting has the problem we’re discussing in this report.

An alternative would be to use colon notation, e.g. package.submodule:Thing.Nested.attribute.

My preference is still for find_object, using dots and with the nesting prohibition.

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.

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.

This is now obsolete.  For a discussion about moving resolve_name to another part of the stdlib, see #12915.