./devel/py-wrapt, Python module for decorators, wrappers and monkey patching

[ CVSweb ] [ Homepage ] [ RSS ] [ Required by ] [ Add to tracker ]


Branch: CURRENT, Version: 1.17.0, Package name: py312-wrapt-1.17.0, Maintainer: pkgsrc-users

A Python module for decorators, wrappers and monkey patching.

The aim of the wrapt module is to provide a transparent object proxy for
Python, which can be used as the basis for the construction of function
wrappers and decorator functions.

The wrapt module focuses very much on correctness. It therefore goes way
beyond existing mechanisms such as functools.wraps() to ensure that
decorators preserve introspectability, signatures, type checking abilities
etc. The decorators that can be constructed using this module will work in
far more scenarios than typical decorators and provide more predictable and
consistent behaviour.

To ensure that the overhead is as minimal as possible, a C extension module
is used for performance critical components. An automatic fallback to a pure
Python implementation is also provided where a target system does not have a
compiler to allow the C extension to be compiled.


Required to run:
[lang/python37]

Required to build:
[pkgtools/cwrappers]

Master sites:

Filesize: 54.24 KB

Version history: (Expand)


CVS history: (Expand)


   2024-11-23 12:06:30 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-wrapt: updated to 1.17.0

Version 1.17.0

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.
   2024-11-11 08:29:31 by Thomas Klausner | Files touched by this commit (862)
Log message:
py-*: remove unused tool dependency

py-setuptools includes the py-wheel functionality nowadays
   2024-05-06 00:15:24 by Thomas Klausner | Files touched by this commit (2)
Log message:
py-wrapt: convert to wheel.mk

Bump PKGREVISION.
   2023-11-09 17:35:24 by Adam Ciarcinski | Files touched by this commit (3) | Package updated
Log message:
py-wrapt: updated to 1.16.0

wrapt-1.16.0
Unknown changes
   2023-02-27 09:33:00 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-wrapt: updated to 1.15.0

Version 1.15.0

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.
   2022-05-02 09:49:33 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-wrapt: updated to 1.14.1

Version 1.14.1

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.
   2022-03-31 10:43:02 by Adam Ciarcinski | Files touched by this commit (3) | Package updated
Log message:
py-wrapt: updated to 1.14.0

Version 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.
   2022-01-04 21:55:40 by Thomas Klausner | Files touched by this commit (1595)
Log message:
*: bump PKGREVISION for egg.mk users

They now have a tool dependency on py-setuptools instead of a DEPENDS