On Tue, Jul 06, 2010 at 10:57:35AM -0400, Ross Vandegrift wrote: > On Tue, Jul 06, 2010 at 04:27:52PM +0300, Marius Gedminas wrote: > > 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>
Gotcha!
The value of __import__.__module__ will tell you what package took it
over.
> > 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.
(Also, 'paster shell' uses IPython, but it works fine on my system with
Python 2.6.)
> 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.
Myghty has been superseded by Mako, why use it?
Marius Gedminas
--
if (Match.FileMatch(F) == true && Fixed[F->ID] == false)
-- apt-pkg/policy.cc (apt 0.5.23)
signature.asc
Description: Digital signature
