On Tue, Jul 06, 2010 at 04:27:52PM +0300, Marius Gedminas wrote:
> Maybe there's something wrong with your system Python? Can you try to
> reproduce with
>
> $ python2.6
> >>> __import__('encodings.latin_1', fromlist=['*'], level=0)
> <module 'encodings.latin_1' from
> '/usr/lib/python2.6/encodings/latin_1.pyc'>
>
> If that works fine (and I expect it will), then maybe some packages in
> your project is trying to hook into Python's import machinery (e.g. by
> overriding __builtin__.__import__), but hasn't updated the API to be
> compatible with Python 2.6.
Yep, you're totally correct:
rvandegr...@malaclypse:~$ python2.6
Python 2.6.5+ (release26-maint, Jul 1 2010, 00:47:18)
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> __import__('encodings.latin_1', fromlist=['*'], level=0)
<module 'encodings.latin_1' from '/usr/lib/python2.6/encodings/latin_1.pyc'>
> Can you get a Paster shell and check if __import__ is still the builtin
> function, or if something has replaced it?
>
> >>> __import__
> <built-in function __import__>
>
> (It would be even better to do that in a pdb session after the actual
> crash.)
"paster shell" won't start, it hits this exception right away. If I
run it under pdb, it looks like:
(Pdb) __import__
<function import_module at 0xaa5cf44>
> Grepping source files on my system I see that Cheetah, IPython, and
> Mercurial, as well as stdlib's ihooks.py, all like to assign to
> __builtin__.__import__.
Hmmm, I use IPython, but that assigns __import__ to deep_import_hook.
Looks like Myghty is the culprit:
./site-packages/Myghty-1.1-py2.6.egg/myghty/importer.py:__builtin__.__import__
= import_module
That's a nice tie-in to my other thread, and means that 2.6 is not an
option for me right now.
Thanks for the help,
Ross
--
Ross Vandegrift
[email protected]
"If the fight gets hot, the songs get hotter. If the going gets tough,
the songs get tougher."
--Woody Guthrie
signature.asc
Description: Digital signature
