[Python-Dev] Re: opcode performance measurements

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

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