import mysteries

[Peter Otten]

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