(original) (raw)

On Sun, Nov 30, 2014 at 1:12 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 30 Nov 2014 11:15:50 -0800
Guido van Rossum <guido@python.org> wrote:
\> On Sun, Nov 30, 2014 at 6:15 AM, Brett Cannon <brett@python.org> wrote:
\> >
\> > On Sat, Nov 29, 2014, 21:55 Guido van Rossum <guido@python.org> wrote:
\> >
\> > All the use cases seem to be about adding some kind of getattr hook to
\> > modules. They all seem to involve modifying the CPython C code anyway. So
\> > why not tackle that problem head-on and modify module\_getattro() to look
\> > for a global named \_\_getattr\_\_ and if it exists, call that instead of
\> > raising AttributeError?
\> >
\> > Not sure if anyone thought of it. :) Seems like a reasonable solution to
\> > me. Be curious to know what the benchmark suite said the impact was.
\> >
\> Why would there be any impact? The \_\_getattr\_\_ hook would be similar to the
\> one on classes -- it's only invoked at the point where otherwise
\> AttributeError would be raised.

builtins are typically found by first looking up in the current globals
(module) scope, failing, and then falling back on \_\_builtins\_\_.

Depending on how much overhead is added to the "failing" step, there
/might/ be a performance difference. Of course, that would only occur
wherever a \_\_getattr\_\_ hook is defined.

The builtins lookup process never does a module attribute lookup -- it only does dict lookups. So it would not be affected by a module \_\_getattr\_\_ hook (unless we were to use dict proxies, which Nathaniel already rejected).

@Nathaniel: perhaps you could get what you want without any C code changes using the approach of Brett's LazyLoader?

--
--Guido van Rossum (python.org/\~guido)