Next | Query returned 18 messages, browsing 11 to 20 | previous

History of commit frequency

CVS Commit History:


   2020-03-17 21:05:53 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-wrapt: updated to 1.12.1

Version 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.

Version 1.12.0

Features Changed

Provided that you only want to support Python 3.7, when deriving from a base \ 
class which has a decorator applied to it, you no longer need to access the true \ 
type of the base class using __wrapped__ in the inherited class list of the \ 
derived class.
Bugs Fixed

When using the synchronized decorator on instance methods of a class, if the \ 
class declared special methods to override the result for when the class \ 
instance was tested as a boolean so that it returned False all the time, the \ 
synchronized method would fail when called.
When using an adapter function to change the signature of the decorated \ 
function, inspect.signature() was returning the wrong signature when an instance \ 
method was inspected by accessing the method via the class type.
   2019-06-18 10:00:34 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-wrapt: updated to 1.11.2

Version 1.11.2
Bugs Fixed
Fix possible crash when garbage collection kicks in when invoking a destructor \ 
of wrapped object.
   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.

Next | Query returned 18 messages, browsing 11 to 20 | previous