Wrapt

--------------

Note that version 1.17.0 drops support for Python 3.6 and 3.7. Python version
3.8 or later is required.

**New Features**

* Add `__format__()` method to `ObjectProxy` class to allow formatting of
wrapped object.

* Added C extension internal flag to indicate that `wrapt` should be safe for
Python 3.13 free threading mode. Releases will include free threading variants
of Python wheels. Note that as free threading is new, one should be cautious
about using it in production until it has been more widely tested.

**Bugs Fixed**

* When a normal function or builtin function which had `wrapt.decorator` or a
function wrapper applied, was assigned as a class attribute, and the function
attribute called via the class or an instance of the class, an additional
argument was being passed, inserted as the first argument, which was the class
or instance. This was not the correct behaviour and the class or instance
should not have been passed as the first argument.

* When an instance of a callable class object was wrapped which didn't not have
a `__get__()` method for binding, and it was called in context whhere binding
would be attempted, it would fail with error that `__get__()` did not exist
when instead it should have been called directly, ignoring that binding was
not possible.

* The `__round__` hook for the object proxy didn't accept `ndigits` argument.

--------------

Note that version 1.16.0 drops support for Python 2.7 and 3.5. Python version
3.6 or later is required.

**New Features**

* The ``patch_function_wrapper()`` decorator now accepts an ``enabled``
argument, which can be a literal boolean value, object that evaluates as
boolean, or a callable object which returns a boolean. In the case of a
callable, determination of whether the wrapper is invoked will be left until
the point of the call. In the other cases, the wrapper will not be applied if
the value evaluates false at the point of applying the wrapper.

**Features Changed**

* The import hook loader and finder objects are now implemented as transparent
object proxies so they properly proxy pass access to attributes/functions of
the wrapped loader or finder.

* Code files in the implementation have been reorganized such that the pure
Python version of the ``ObjectProxy`` class is directly available even if the
C extension variant is being used. This is to allow the pure Python variant to
be used in exceptional cases where the C extension variant is not fully
compatible with the pure Python implementation and the behaviour of the pure
Python variant is what is required. This should only be relied upon if have
absolutely no choice. The pure Python variant is not as performant as the C
extension.

To access the pure Python variant use ``from wrapt.wrappers import ObjectProxy``
instead of just ``from wrapt import ObjectProxy``. Note that prior to this
version if you had used ``from wrapt.wrappers import ObjectProxy`` you would
have got the C extension variant of the class rather than the pure Python
version if the C extension variant was available.

**Bugs Fixed**

* It was not possible to update the ``__class__`` attribute through the
transparent object proxy when relying on the C implementation.

--------------

**Bugs Fixed**

* When the C extension for wrapt was being used, and a property was used on an
object proxy wrapping another object to intercept access to an attribute of
the same name on the wrapped object, if the function implementing the property
raised an exception, then the exception was ignored and not propagated back to
the caller. What happened instead was that the original value of the attribute
from the wrapped object was returned, thus silently suppressing that an
exception had occurred in the wrapper. This behaviour was not happening when
the pure Python version of wrapt was being used, with it raising the
exception. The pure Python and C extension implementations thus did not behave
the same.

Note that in the specific case that the exception raised is AttributeError it
still wouldn't be raised. This is the case for both Python and C extension
implementations. If a wrapper for an attribute internally raises an
AttributeError for some reason, the wrapper should if necessary catch the
exception and deal with it, or propagate it as a different exception type if
it is important that an exception still be passed back.

* Address issue where the post import hook mechanism of wrapt wasn't transparent
and left the ``__loader__`` and ``__spec__.loader`` attributes of a module as
the wrapt import hook loader and not the original loader. That the original
loader wasn't preserved could interfere with code which needed access to the
original loader.

* Address issues where a thread deadlock could occur within the wrapt module
import handler, when code executed from a post import hook created a new
thread and code executed in the context of the new thread itself tried to
register a post import hook, or imported a new module.

* When using ``CallableObjectProxy`` as a wrapper for a type or function and
calling the wrapped object, it was not possible to pass a keyword argument
named ``self``. This only occurred when using the pure Python version of wrapt
and did not occur when using the C extension based implementation.

* When using ``PartialCallableObjectProxy`` as a wrapper for a type or function,
when constructing the partial object and when calling the partial object, it
was not possible to pass a keyword argument named ``self``. This only occurred
when using the pure Python version of wrapt and did not occur when using the C
extension based implementation.

* When using ``FunctionWrapper`` as a wrapper for a type or function and calling
the wrapped object, it was not possible to pass a keyword argument named
``self``. Because ``FunctionWrapper`` is also used by decorators, this also
affected decorators on functions and class types. A similar issue also arose
when these were applied to class and instance methods where binding occurred
when the method was accessed. In that case it was in ``BoundFunctionWrapper``
that the problem could arise. These all only occurred when using the pure
Python version of wrapt and did not occur when using the C extension based
implementation.

* When using ``WeakFunctionProxy`` as a wrapper for a function, when calling the
function via the proxy object, it was not possible to pass a keyword argument
named ``self``.

--------------

**Bugs Fixed**

* When the post import hooks mechanism was being used, and a Python package with
its own custom module importer was used, importing modules could fail if the
custom module importer didn't use the latest Python import hook finder/loader
APIs and instead used the deprecated API. This was actually occurring with the
``zipimporter`` in Python itself, which was not updated to use the newer
Python APIs until Python 3.10.

--------------

**Bugs Fixed**

* Python 3.11 dropped ``inspect.formatargspec()`` which was used in creating
signature changing decorators. Now bundling a version of this function
which uses ``Parameter`` and ``Signature`` from ``inspect`` module when
available. The replacement function is exposed as ``wrapt.formatargspec()``
if need it for your own code.

* When using a decorator on a class, ``isinstance()`` checks wouldn't previously
work as expected and you had to manually use ``Type.__wrapped__`` to access
the real type when doing instance checks. The ``__instancecheck__`` hook is
now implemented such that you don't have to use ``Type.__wrapped__`` instead
of ``Type`` as last argument to ``isinstance()``.

* Eliminated deprecation warnings related to Python module import system, which
would have turned into broken code in Python 3.12. This was used by the post
import hook mechanism.

**New Features**

* Binary wheels provided on PyPi for ``aarch64`` Linux systems and macOS
native silicon where supported by Python when using ``pypa/cibuildwheel``.

--------------

**New Features**

* Adds wheels for Python 3.10 on PyPi and where possible also now
generating binary wheels for ``musllinux``.