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

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


Branch: CURRENT, Version: 1.11.1, Package name: py27-wrapt-1.11.1, 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/python27]

Required to build:
[pkgtools/cwrappers]

Master sites:

SHA1: e40a3b628c9b5503d47160d08d1bf93a2c7471fe
RMD160: 3a61778530d5de6f4773fe671b111c82578c8859
Filesize: 26.587 KB

Version history: (Expand)


CVS history: (Expand)


   2019-01-21 11:31:16 by Adam Ciarcinski | Files touched by this commit (3) | Package updated
Log message:
py-wrapt: updated to 1.11.1

Version 1.11.1

Bugs Fixed

Fixed memory leak in C extension variant of PartialCallableObjectProxy class \ 
introduced in 1.11.0, when it was being used to perform binding, when a call of \ 
an instance method was made through the class type, and the self object passed \ 
explicitly as first argument.
The C extension variant of the PartialCallableObjectProxy class introduced in \ 
1.11.0, which is a version of functools.partial which correctly handles binding \ 
when applied to methods of classes, couldn't be used when no positional \ 
arguments were supplied.
When the C extension variant of PartialCallableObjectProxy was used and multiple \ 
positional arguments were supplied, the first argument would be replicated and \ 
used to all arguments, instead of correct values, when the partial was called.
When the C extension variant of PartialCallableObjectProxy was used and keyword \ 
arguments were supplied, it would fail as was incorrectly using the positional \ 
arguments where the keyword arguments should have been used.

Version 1.11.0

Bugs Fixed

When using arithmetic operations through a proxy object, checks about the types \ 
of arguments were not being performed correctly, which could result in an \ 
exception being raised to indicate that a proxy object had not been initialised \ 
when in fact the argument wasn't even an instance of a proxy object.

Because an incorrect cast in C level code was being performed and an attribute \ 
in memory checked on the basis of it being a type different to what it actually \ 
was, technically it may have resulted in a process crash if the size of the \ 
object was smaller than the type being casted to.

The __complex__() special method wasn't implemented and using complex() on a \ 
proxy object would give wrong results or fail.

When using the C extension, if an exception was raised when using inplace or, \ 
ie., |=, the error condition wasn't being correctly propagated back which would \ 
result in an exception showing up as wrong location in subsequent code.

Type of long was used instead of Py_hash_t for Python 3.3+. This caused compiler \ 
warnings on Windows, which depending on what locale was set to, would cause pip \ 
to fail when installing the package.

If calling Class.instancemethod and passing self explicitly, the ability to \ 
access __name__ and __module__ on the final bound method were not preserved. \ 
This was due to a partial being used for this special case, and it doesn't \ 
preserve introspection.

Fixed typo in the getter property of ObjectProxy for accessing __annotations__. \ 
Appeared that it was still working as would fall back to using generic \ 
__getattr__() to access attribute on wrapped object.
   2017-08-16 20:07:32 by Adam Ciarcinski | Files touched by this commit (2)
Log message:
Version 1.10.11

Bugs Fixed
* When wrapping a @classmethod in a class used as a base class, when the method \ 
was called via the derived class type, the base class type was being passed for \ 
the cls argument instead of the derived class type through which the call was \ 
made.

New Features
* The C extension can be disabled at runtime by setting the environment variable \ 
WRAPT_DISABLE_EXTENSIONS. This may be necessary where there is currently a \ 
difference in behaviour between pure Python implementation and C extension and \ 
the C extension isn't having the desired result.
   2017-07-31 00:32:28 by Thomas Klausner | Files touched by this commit (229)
Log message:
Switch github HOMEPAGEs to https.
   2017-07-16 21:55:03 by Adam Ciarcinski | Files touched by this commit (1)
Log message:
Added 'python' to CATEGORIES
   2017-06-07 16:42:26 by Ryo ONODERA | Files touched by this commit (40)
Log message:
Fix build with Perl 5.26.0
   2016-05-05 13:15:33 by Richard PALO | Files touched by this commit (4)
Log message:
add devel/py-wrapt (wrapt-1.10.8)

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.