[Python-Dev] Re: opcode performance measurements

[Gordon McMillan]

On 31 Jan 2002 at 20:13, Jeremy Hylton wrote:


>   GM> How can the compiler tell it's a package import?
> 
> I'm assuming it can guess based on import
> statements and that a runtime check in
> LOAD_GLOBAL_ATTR (or whatever it's called) can
> verify this assumption.  I haven't thought this part
> through fully, because I'm not aware of the full
> perversity of what people do with import hooks. 

Import hooks are effectively dead. People play namespace games almost exclusively now.
 
>   GM> It's bad practice, but people write "import
>   mod.attr" all the GM> time.
> 
> I write it all the time when attr is a module in a
> package.  And I know I can't do it for an actual
> attr of module. 

import os.path works even though there's no module named path. import pkg.attr always works.
 
>   GM>       Heck, Marc-Andre tricks import so that
>   pkg.mod is really GM> pkg.attr where the attr turns
>   into a mod when accessed. No GM> problem, since it's
>   only import that cares what it is. By the GM> time
>   it's used it's always global.attr.attr....
> 
> Not sure I understand what Marc-Andre is doing.
> (That's probably true in general <wink>.)  A client of
> his code types "import foo.bar." foo is a module?  a
> package?  When the "bar" attribute is loaded
> (LOAD_ATTR) is turns into another module?

foo is a package. The __init__.py creates an instance of LazyModule named bar. Doing anything with foo.bar triggers an import, and replacment of the name 
"bar" in foo with module bar.

That one's clean. Now turn your eye on the shennanigans in PyXML.

-- Gordon
http://www.mcmillan-inc.com/