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

Koos Zevenhoven k7hoven at gmail.com
Wed Nov 15 07:55:53 EST 2017

On Tue, Nov 14, 2017 at 10:34 PM, Ivan Levkivskyi <levkivskyi at gmail.com> wrote: ​[..]​

Rationale =========

It is sometimes convenient to customize or otherwise have control over access to module attributes. A typical example is managing deprecation warnings. Typical workarounds are assigning _class_ of a module object to a custom subclass of types.ModuleType or replacing the sys.modules item with a custom wrapper instance. It would be convenient to simplify this procedure by recognizing _getattr_ defined directly in a module that would act like a normal _getattr_ method, except that it will be defined on module instances. For example::

lib.py

from warnings import warn deprecatednames = ["oldfunction", ...] def deprecatedoldfunction(arg, other): ... def getattr(name): if name in deprecatednames: warn(f"{name} is deprecated", DeprecationWarning) return globals()[f"deprecated{name}"] raise AttributeError(f"module {name} has no attribute {name}") # main.py from lib import oldfunction # Works, but emits the warning ​Deprecating functions is already possible, so I assume the reason for this would be performance? If so, are you sure this would help for performance? ​ ​Deprecating module attributes / globals is indeed difficult to do at present. This PEP would allow deprecation warnings for accessing attributes, which is nice! However, as thread-unsafe as it is, many modules use module attributes to configure the state of the module. In that case, the user is more likely to set the attribute that to get it. Is this outside the scope of the PEP?

​[..]​

There is a related proposal PEP 549 that proposes to support instance properties for a similar functionality. The difference is this PEP proposes a faster and simpler mechanism, but provides more basic customization.

​I'm not surprised that the comparison is in favor of this PEP ;-).​

​[..]​

Specification =============

The _getattr_ function at the module level should accept one argument which is the name of an attribute and return the computed value or raise an AttributeError:: def getattr(name: str) -> Any: ... This function will be called only if name is not found in the module through the normal attribute lookup. The Rationale (quoted in the beginning of this email) easily leaves a different impression of this.​

​[..] ​

Discussion ========== Note that the use of module _getattr_ requires care to keep the referred objects pickleable. For example, the _name_ attribute of a function should correspond to the name with which it is accessible via _getattr_:: def keeppickleable(func): func.name = func.name.replace('deprecated', '') func.qualname = func.qualname.replace('deprecated', '') return func @keeppickleable def deprecatedoldfunction(arg, other): ... One should be also careful to avoid recursion as one would do with a class level _getattr_. Off-topic: In some sense, I'm happy to hear something about pickleability. But in some sense not.

I think there are three kinds of people regarding pickleability:

  1. Those who don't care about anything being pickleable

  2. Those ​who care about some things being picklable

​3. ​Those who care about all things being picklable

Personally, I'd like to belong to group 3, but because group 3 cannot even attempt to coexist with groups 1 and 2, I actually belong to group 1 most of the time.

​––Koos ​

References ==========

.. [1] PEP 484 section about _getattr_ in stub files (https://www.python.org/dev/peps/pep-0484/#stub-files) .. [2] The reference implementation (https://github.com/ilevkivskyi/cpython/pull/3/files)

Copyright ========= This document has been placed in the public domain.

.. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

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/ k7hoven%40gmail.com

--

More information about the Python-Dev mailing list