[pypy-dev] Re: [py-dev] Re: Error with py.test and scipy ...
hpk at trillke.net
Fri Apr 8 01:43:41 CEST 2005
On Fri, Apr 08, 2005 at 01:33 +0200, Valentino Volonghi aka Dialtone wrote:
> holger krekel wrote:
> >I would be surprised if my brand-new hack breaks yours (because that
> >is exactly what it is trying to avoid) but i've learned that "import"
> >makes the impossible possible and vice versa.
> It was a quick fix in my case :).
Everybody says that, see "piles of hacks" earlier :-)
> It shouldn't be hard to figure out a common failing pattern in import
> magic. for example:
> nevow was failing because of namedAny that imports a module from a
> string representing the entire path in PYTHONPATH.
brain shaking already ...
> from nevow import util
> In :util.namedAny('nevow.flat.ten')
> Out:<module 'nevow.flat.ten' from
> namedAny is this one:
> def namedAny(name):
> """Get a fully named package, module, module-global object, or
> names = name.split('.')
> topLevelPackage = None
> moduleNames = names[:]
> while not topLevelPackage:
> trialname = '.'.join(moduleNames)
> topLevelPackage = __import__(trialname)
> except ImportError:
> # if the ImportError happened in the module being imported,
> # this is a failure that should be handed to our caller.
> # count stack frames to tell the difference.
> # string-matching is another technique, but I think it could be
> # fooled in some funny cases
> #if sys.exc_info() != "cannot import name %s" % trialname:
> # raise
> import traceback
> if len(traceback.extract_tb(sys.exc_info())) > 1:
> obj = topLevelPackage
> for n in names[1:]:
> obj = getattr(obj, n)
> return obj
> But I can't remember exactly the failure. The ML is here to help
> (something about the PYTHONPATH anyway).
I have written similar code and there were always side cases
that made it at least hard to debug and find the actual problem
in the program.
More information about the Pypy-dev