Wrapt

Latest version: v1.17.2

Safety actively analyzes 714815 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 2 of 8

1.14.0

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

**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``.

1.13.3

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

**New Features**

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

1.13.2

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

**Features Changed**

* On the Windows platform when using Python 2.7, by default the C extension
will not be installed and the pure Python implementation will be used.
This is because too often on Windows when using Python 2.7, there is no
working compiler available. Prior to version 1.13.0, when installing the
package it would fallback to using the pure Python implementation
automatically but that relied on a workaround to do it when there was
no working compiler. With the changes in 1.13.0 to use the builtin
mechanism of Python to not fail when a C extension cannot be compiled,
this fallback doesn't work when the compiler doesn't exist, as the
builtin mechanism in Python regards lack of a compiler as fatal and not
a condition for which it is okay to ignore the fact that the extension
could not be compiled.

If you are using Python 2.7 on Windows, have a working compiler, and
still want to attempt to install the C extension, you can do so by
setting the `WRAPT_INSTALL_EXTENSIONS` environment variable to `true`
when installing the `wrapt` package.

Note that the next signficant release of `wrapt` will drop support for
Python 2.7 and Python 3.5. The change described here is to ensure that
`wrapt` can be used with Python 2.7 on Windows for just a little bit
longer. If using Python 2.7 on non Windows platforms, it will still
attempt to install the C extension.

1.13.1

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

**Bugs Fixed**

* Fix Python version constraint so PyPi classifier for ``pip`` requires
Python 2.7 or Python 3.5+.

1.13.0

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

**Bugs Fixed**

* When a reference to a class method was taken out of a class, and then
wrapped in a function wrapper, and called, the class type was not being
passed as the instance argument, but as the first argument in args,
with the instance being ``None``. The class type should have been passed
as the instance argument.

* If supplying an adapter function for a signature changing decorator
using input in the form of a function argument specification, name lookup
exceptions would occur where the adaptor function had annotations which
referenced non builtin Python types. Although the issues have been
addressed where using input data in the format usually returned by
``inspect.getfullargspec()`` to pass the function argument specification,
you can still have problems when supplying a function signature as
string. In the latter case only Python builtin types can be referenced
in annotations.

* When a decorator was applied on top of a data/non-data descriptor in a
class definition, the call to the special method ``__set_name__()`` to
notify the descriptor of the variable name was not being propogated. Note
that this issue has been addressed in the ``FunctionWrapper`` used by
``wrapt.decorator`` but has not been applied to the generic
``ObjectProxy`` class. If using ``ObjectProxy`` directly to construct a
custom wrapper which is applied to a descriptor, you will need to
propogate the ``__set_name__()`` call yourself if required.

* The ``issubclass()`` builtin method would give incorrect results when used
with a class which had a decorator applied to it. Note that this has only
been able to be fixed for Python 3.7+. Also, due to what is arguably a
bug (https://bugs.python.org/issue44847) in the Python standard library,
you will still have problems when the class heirarchy uses a base class
which has the ``abc.ABCMeta`` metaclass. In this later case an exception
will be raised of ``TypeError: issubclass() arg 1 must be a class``.

1.12.1

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

**Bugs Fixed**

* Applying a function wrapper to a static method of a class using the
``wrap_function_wrapper()`` function, or wrapper for the same, wasn't
being done correctly when the static method was the immediate child of
the target object. It was working when the name path had multiple name
components. A failure would subsequently occur when the static method
was called via an instance of the class, rather than the class.

Page 2 of 8

© 2025 Safety CLI Cybersecurity Inc. All Rights Reserved.