David Abrahams wrote: > > on Thu Jun 21 2007, Peter Otten <__peter__-AT-web.de> wrote: > >> David Abrahams wrote: >> >>> I'm pretty comfortable with Python, but recently I'm constantly >>> finding mysterious issues with import. For example, looking at >>> >>> http://genshi.edgewall.org/browser/trunk/genshi/filters/transform.py >>> >>> the examples use the symbol 'HTML' but it's not defined locally, it's >>> not explicitly imported, and there's no import *. Yet doctest will >>> test this module and it passes with flying colors. It turns out HTML >>> is defined in genshi.input. How do I know that? I grepped for it. >>> How does it become available to this module? >> >> Explicitly passed, see >> >> http://genshi.edgewall.org/browser/trunk/genshi/filters/tests/transform.py > > IIRC I ran doctest on the file I cited, not the one you're pointing > at. Is there some new magic doctest feature I should know about?
Had you looked at it you'd seen that the file I pointed to is the driver script for running the doctests in the file you pointed to -- unfortunately they have the same name. [...]/tests/transform.py does indeed inject a HTML object into the globals of [...]/filters/transform.py before it runs the tests. >>> Another example: I was recently working on some code that did an >>> import from inside a class method. That import was failing. I moved >>> the import to the top of the file (at module scope) and it succeeded. >>> I'm fairly sure that nobody was monkeying around with sys.path in that >>> case. Can anyone think of a likely explanation? >> >> Too vague, sorry. > > # this will succeed if I do it here > # import foo.bar > > class X: > def y(): > import foo.bar # but this fails Are threads involved? I vaguely remember a problem with Queue.Queue that came up on this list some time ago. Peter -- http://mail.python.org/mailman/listinfo/python-list
