Suggestion for improved ImportError message

3 views
Skip to first unread message

Kent Tenney

unread,
Aug 13, 2008, 4:55:38 PM8/13/08
to pytho...@python.org
Howdy,

I was just bit by

from image import annotate

ImportError: cannot import name annotate

I found the problem via

import image
print image.__file__

which made it clear that the wrong image module had been found.

It would be nice if ImportError announced this up front.

cannot import name annotate from /usr/<snip>/image.pyc

Thanks,
Kent

Wojtek Walczak

unread,
Aug 13, 2008, 6:15:48 PM8/13/08
to
Dnia Wed, 13 Aug 2008 20:55:38 +0000 (UTC), Kent Tenney napisa³(a):

> from image import annotate
>
> ImportError: cannot import name annotate
>
> I found the problem via
>
> import image
> print image.__file__
>
> which made it clear that the wrong image module had been found.
>
> It would be nice if ImportError announced this up front.

Then go for it :-) You can prepare a patch and ask on python-dev
if the developers are interested.

I was never hacking the import things on C level before,
but a hint: you have to modify import_from function from
Python/ceval.c

My quick attempt:
http://www.stud.umk.pl/~wojtekwa/patches/from-import-py2.5.1.patch


--
Regards,
Wojtek Walczak,
http://www.stud.umk.pl/~wojtekwa/

Fredrik Lundh

unread,
Aug 13, 2008, 6:27:11 PM8/13/08
to pytho...@python.org
Kent Tenney wrote:

> I was just bit by
>

> from image import annotate
>
> ImportError: cannot import name annotate
>
> I found the problem via
>
> import image
> print image.__file__
>
> which made it clear that the wrong image module had been found.

that's what "python -v" is all about, of course.

</F>

Wojtek Walczak

unread,
Aug 13, 2008, 6:39:58 PM8/13/08
to
Dnia Wed, 13 Aug 2008 22:15:48 +0000 (UTC), Wojtek Walczak napisa³(a):

> Then go for it :-) You can prepare a patch and ask on python-dev
> if the developers are interested.
>
> I was never hacking the import things on C level before,
> but a hint: you have to modify import_from function from
> Python/ceval.c
>
> My quick attempt:
> http://www.stud.umk.pl/~wojtekwa/patches/from-import-py2.5.1.patch

Uh, and an example:

Python 2.5.1 (r251:54863, Aug 14 2008, 00:04:00)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from os import qweasd
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: cannot import name qweasd (/home/gminick/Python-2.5.1/Lib/os.pyc)

Kent Tenney

unread,
Aug 13, 2008, 9:35:44 PM8/13/08
to pytho...@python.org
> > Then go for it You can prepare a patch and ask on python-dev

> > if the developers are interested.

hehe, I'll get a C level patch accepted right after I
out-swim Mike Phelps.

> >
> > I was never hacking the import things on C level before,
> > but a hint: you have to modify import_from function from
> > Python/ceval.c

Am I correct in thinking that PyPy would mean low level
stuff like this will be Python instead of C?
That would be nice.

> >
> > My quick attempt:

Quick indeed!
Very cool.

Thanks,
Kent

Wojtek Walczak

unread,
Aug 14, 2008, 6:10:56 AM8/14/08
to
On Thu, 14 Aug 2008 01:35:44 +0000 (UTC), Kent Tenney wrote:
>> > Then go for it You can prepare a patch and ask on python-dev
>> > if the developers are interested.
>
> hehe, I'll get a C level patch accepted right after I
> out-swim Mike Phelps.

It's really not that hard. The only hard thing (harder than
writing the code) might be to win the acceptance of the core
developers that this change is really needed ;-)


>> > I was never hacking the import things on C level before,
>> > but a hint: you have to modify import_from function from
>> > Python/ceval.c
>
> Am I correct in thinking that PyPy would mean low level
> stuff like this will be Python instead of C?
> That would be nice.

I don't know PyPy, but I guess you're right here.

Lie

unread,
Aug 15, 2008, 6:23:16 AM8/15/08
to
On Aug 14, 5:10 pm, Wojtek Walczak

<gmin...@nie.ma.takiego.adresu.w.sieci.pl> wrote:
> On Thu, 14 Aug 2008 01:35:44 +0000 (UTC), Kent Tenney wrote:
> >> > Then go for it  You can prepare a patch and ask on python-dev
> >> > if the developers are interested.
>
> > hehe, I'll get a C level patch accepted right after I
> > out-swim Mike Phelps.
>
> It's really not that hard. The only hard thing (harder than
> writing the code) might be to win the acceptance of the core
> developers that this change is really needed ;-)

I think the acceptance for this wouldn't be that hard since there is
no real issue for regression (the only one I could think of is for
doctest module, although I'm not sure there are any reason to test for
failed import in doctest)

bearoph...@lycos.com

unread,
Aug 15, 2008, 8:42:01 AM8/15/08
to
Lie:

>I'm not sure there are any reason to test for failed import in doctest)<

I have code that uses numpy if available, otherwise uses slower normal
Python code. Inside the doctests I'd like to test both situations...

Bye,
bearophile

Benjamin

unread,
Aug 15, 2008, 10:58:28 PM8/15/08
to
On Aug 13, 3:55 pm, Kent Tenney <kten...@gmail.com> wrote:
> Howdy,
>
> I was just bit by
>
> from image import annotate
>
> ImportError: cannot import name annotate
>
> I found the problem via
>
> import image
> print image.__file__
>
> which made it clear that the wrong image module had been found.
>
> It would be nice if ImportError announced this up front.

Why? It says the file where the error originated in the traceback.

Lie

unread,
Aug 23, 2008, 12:53:50 PM8/23/08
to

Why? Is there a difference in result if you have used numpy and python
code? If that is, I smell a bad code. What numpy and python code
version would return in that situation should be the same (practically
it isn't always feasible though).

> Bye,
> bearophile

Fredrik Lundh

unread,
Aug 23, 2008, 1:08:13 PM8/23/08
to pytho...@python.org
Lie wrote:

>> I have code that uses numpy if available, otherwise uses slower normal
>> Python code. Inside the doctests I'd like to test both situations...
>
> Why? Is there a difference in result if you have used numpy and python
> code? If that is, I smell a bad code. What numpy and python code
> version would return in that situation should be the same (practically
> it isn't always feasible though).

maybe the point is to use doctest to *verify* that the code generates
the same result whether or not numpy is used?

</F>

Reply all
Reply to author
Forward
0 new messages