471,334 Members | 1,363 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,334 software developers and data experts.

import mysteries


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/t...s/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?

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?

TIA,

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==http://www.astoriaseminar.com

Jun 21 '07 #1
11 1234
David Abrahams schrieb:
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/t...s/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 doesn't pass for me:

pydoctest.testmod(genshi.filters.transform)
************************************************** ********************
File "/usr/lib/python2.4/site-packages/genshi/filters/transform.py",
line 29, in genshi.filters.transform
Failed example:
html = HTML('''<html>
<head><title>Some Title</title></head>
<body>
Some <em>body</emtext.
</body>
</html>''')
Exception raised:
Traceback (most recent call last):
File "doctest.py", line 1248, in __run
compileflags, 1) in test.globs
File "<doctest genshi.filters.transform[1]>", line 1, in ?
html = HTML('''<html>
NameError: name 'HTML' is not defined

Regards,
Martin
Jun 21 '07 #2
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/t...s/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/t...s/transform.py
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.

Peter
Jun 21 '07 #3
David Abrahams <da**@boost-consulting.comwrites:
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/t...s/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?
That's a mystery to me too. I can't see by looking at the module where
this 'HTML' name comes from, and as you say there is no import of
'genshi.input'.

Whatever the explanation, it's a violation of one of the strengths of
Python: namespaces. Names that appear in the current namespace (as
happens with 'from foo import *', and as seems to be happening here)
are bad programming style, for exactly the reason that they make the
code more difficult to understand.

--
\ "bash awk grep perl sed, df du, du-du du-du, vi troff su fsck |
`\ rm * halt LART LART LART!" -- The Swedish BOFH, |
_o__) alt.sysadmin.recovery |
Ben Finney
Jun 22 '07 #4
On Thu, 21 Jun 2007 16:03:42 -0400, 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/t...s/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?
There are ways to bypass the import system. The most obvious would be to
write directly to globals.
>>spanish_inquisition
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'spanish_inquisition' is not defined
>>globals()['spanish_inquisition'] = "NOBODY expects the Spanish
Inquisition!!!"
>>spanish_inquisition
'NOBODY expects the Spanish Inquisition!!!'
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?
If it was a "from MODULE import *" then it will not work if it is nested
in a function or class. That's by design.

--
Steven.
Jun 22 '07 #5

on Fri Jun 22 2007, "Steven D'Aprano" <steven-AT-REMOVE.THIS.cybersource.com.auwrote:
There are ways to bypass the import system. The most obvious would be to
write directly to globals.
>>>spanish_inquisition
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'spanish_inquisition' is not defined
>>>globals()['spanish_inquisition'] = "NOBODY expects the Spanish
Inquisition!!!"
>>>spanish_inquisition
'NOBODY expects the Spanish Inquisition!!!'
Yeah, of course. I just don't think anything that perverse is
happening in these cases. Take, for another example,
http://trac.edgewall.org/ticket/5646#comment:3

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==http://www.astoriaseminar.com

Jul 3 '07 #6

on Thu Jun 21 2007, Ben Finney <bignose+hates-spam-AT-benfinney.id.auwrote:
David Abrahams <da**@boost-consulting.comwrites:
>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/t...s/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?

That's a mystery to me too. I can't see by looking at the module where
this 'HTML' name comes from, and as you say there is no import of
'genshi.input'.

Whatever the explanation, it's a violation of one of the strengths of
Python: namespaces. Names that appear in the current namespace (as
happens with 'from foo import *', and as seems to be happening here)
are bad programming style, for exactly the reason that they make the
code more difficult to understand.
Sometimes that's true, but I disagree with it as a general rule. Some
bindings are idiomatic, in widespread use throughout a project, and
would look dumb and make the code too verbose and hard-to-understand
if qualified (especially if fully qualified).

The practice may make it harder to understand when something goes wrong, but
that's a separate issue.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==http://www.astoriaseminar.com

Jul 3 '07 #7

on Thu Jun 21 2007, Peter Otten <__peter__-AT-web.dewrote:
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/t...s/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/t...s/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?
>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
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==http://www.astoriaseminar.com

Jul 3 '07 #8
Yeah, of course. I just don't think anything that perverse is
happening in these cases. Take, for another example,
http://trac.edgewall.org/ticket/5646#comment:3
[that perverse == putting a name into globals()]

When you do gettext.install(...), it will put the name _ into
the __builtins__. Apparently, the trac code relies on that.

Regards,
Martin
Jul 4 '07 #9
David Abrahams wrote:
>
on Thu Jun 21 2007, Peter Otten <__peter__-AT-web.dewrote:
>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/t...s/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/t...s/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

Jul 4 '07 #10

on Wed Jul 04 2007, Peter Otten <__peter__-AT-web.dewrote:
>>Explicitly passed, see

http://genshi.edgewall.org/browser/t...s/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
Gimme a little credit, please! Of course I 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
Yes, I saw that, but I don't know of any magic feature that causes the
driver script to get loaded when I invoke doctest directly on the file
I 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.
Yes, I saw that, but as I said...

Anyway, maybe I just got confused and doctest-ed the driver script.
That certainly would explain everything.
>>>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.
I don't know, honestly. This was probably in Trac somewhere. I don't
know if it's threaded.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==http://www.astoriaseminar.com

Jul 5 '07 #11
David Abrahams wrote:
>
on Wed Jul 04 2007, Peter Otten <__peter__-AT-web.dewrote:
>>>Explicitly passed, see

http://genshi.edgewall.org/browser/t...s/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

Gimme a little credit, please! Of course I looked at it.
Sorry.
>you'd seen that the file I pointed to is the driver
script for running the doctests in the file you pointed to

Yes, I saw that, but I don't know of any magic feature that causes the
driver script to get loaded when I invoke doctest directly on the file
I pointed to.
Nor do I.
>-- 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.

Yes, I saw that, but as I said...

Anyway, maybe I just got confused and doctest-ed the driver script.
That certainly would explain everything.
Compelling assumption because it does away with the mystery...

Peter
Jul 5 '07 #12

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Stian Søiland | last post: by
reply views Thread by Vio | last post: by
5 posts views Thread by Steve Holden | last post: by
7 posts views Thread by David Poundall | last post: by
reply views Thread by Prem Mallappa | last post: by
2 posts views Thread by dbuchanan | last post: by
9 posts views Thread by rsoh.woodhouse | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.