[Python-Dev] PEP 562 (original) (raw)

Guido van Rossum guido at python.org
Wed Nov 15 11:27:04 EST 2017

I think it's reasonable for the PEP to include some examples, consequences and best practices. I don't think it's reasonable for the PEP to also define the API and implementation of helper functions that might be added once the mechanisms are in place. Those are better developed as 3rd party packages first.

On Wed, Nov 15, 2017 at 3:59 AM, Serhiy Storchaka <storchaka at gmail.com> wrote:

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

On 15 November 2017 at 08:43, Serhiy Storchaka <storchaka at gmail.com_ _<mailto:storchaka at 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. lazyimport() 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 lazyinitialized(). 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.propertiesname elif 'getattr' in self.dict: call self.dict'getattr' else: raise AttributeError I'm wondering if the setname mechanism can be extended to modules. What if call the setname() method for all items in a module dict after finishing importing the module?

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

-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171115/c1e57ad7/attachment.html>

More information about the Python-Dev mailing list