(original) (raw)

15.11.17 12:53, Ivan Levkivskyi пише:

On 15 November 2017 at 08:43, Serhiy Storchaka <storchaka@gmail.com storchaka@gmail.com>> wrote:

It is worth to mention that using name as a module global will
bypass \_\_getattr\_\_. And this is intentional, otherwise calling
\_\_getattr\_\_ for builtins will harm a performance.


Good point!

And please document idiomatic way of using a module global with triggering \_\_getattr\_\_. For example if you want to use a lazy loaded submodule.

sys.modules\[\_\_name\_\_\].foobar

or

from . import foobar

The difference between them that the latter sets the module attribute, thus \_\_getattr\_\_ will be called only once.

Backwards compatibility and impact on performance
\=================================================


What is affect on pydoc, word completion, inspect, pkgutil, unittest?


This is rather gray area. I am not sure that we need to update them in any way, just the people who use \_\_getattr\_\_ should be aware that
some tools might not yet expect it.. I will add a note to the PEP about this.

This problem is not new, since it was possible to replace a module with a module subclass with overridden \_\_getattr\_\_ and \_\_dir\_\_ before, but now this problem can occur more often.

I would create more standard helpers (for deprecation, for lazy
importing). This feature is helpful not by itself, but because it
will be used for implementing new features. Using \_\_getattr\_\_
directly will need to write a boilerplate code. Maybe when
implementing these helper you will discover that this PEP needs some
additions.



But in which module these helpers should live?

Good question. lazy\_import() could be added in importlib (or importlib.util?). The helper that just adds deprecation on importing a name, could be added in importlib too. But I think that it would be better if the deprecated() helper will also create a wrapper that raises a deprecation warning on the use of deprecated function. It could be added in the warnings or functools modules.

I would add also a more general lazy\_initialized(). It is something like cached module property. Executes the specified code on first use, and cache the result as a module attribute.

In all these cases the final \_\_getattr\_\_ method should be automatically constructed from different chunks. At the end it could call a user supplied \_\_getattr\_\_. Or maybe the module method \_\_getattr\_\_ should look first at special registry before calling the instance attribute \_\_getattr\_\_()?

def ModuleType.\_\_getattr\_\_(self, name):
if name in self.\_\_properties\_\_:
call self.\_\_properties\_\_\[name\]()
elif '\_\_getattr\_\_' in self.\_\_dict\_\_:
call self.\_\_dict\_\_\['\_\_getattr\_\_'\](name)
else:
raise AttributeError

I'm wondering if the \_\_set\_name\_\_ mechanism can be extended to modules. What if call the \_\_set\_name\_\_() method for all items in a module dict after finishing importing the module?

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org