[Python-Dev] Re: opcode performance measurements (original) (raw)

Jeremy Hylton jeremy@alum.mit.edu
Thu, 31 Jan 2002 20:13:16 -0500

"GM" == Gordon McMillan <gmcm@hypernet.com> writes:

GM> On 31 Jan 2002 at 6:12, Jeremy Hylton wrote:

import mod.sub creates a binding for "mod" in the global namespace

The compiler can detect that the import statement is a package import -- and mark "mod.sub" as a candidate for optimization. A use of "mod.sub.attr" in function should be treated just as "mod.attr".

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.

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.

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 .) 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?

Jeremy