The NetBSD Project

CVS log for pkgsrc/devel/py-wrapt/Makefile

[BACK] Up to [cvs.NetBSD.org] / pkgsrc / devel / py-wrapt

Request diff between arbitrary revisions


Default branch: MAIN


Revision 1.16 / (download) - annotate - [select for diffs], Thu Nov 9 16:35:24 2023 UTC (3 months, 2 weeks ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2023Q4-base, pkgsrc-2023Q4, HEAD
Changes since 1.15: +2 -2 lines
Diff to previous 1.15 (colored)

py-wrapt: updated to 1.16.0

wrapt-1.16.0
Unknown changes

Revision 1.15 / (download) - annotate - [select for diffs], Mon Feb 27 08:33:00 2023 UTC (12 months ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2023Q3-base, pkgsrc-2023Q3, pkgsrc-2023Q2-base, pkgsrc-2023Q2, pkgsrc-2023Q1-base, pkgsrc-2023Q1
Changes since 1.14: +2 -2 lines
Diff to previous 1.14 (colored)

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.

Revision 1.14 / (download) - annotate - [select for diffs], Mon May 2 07:49:32 2022 UTC (21 months, 4 weeks ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2022Q4-base, pkgsrc-2022Q4, pkgsrc-2022Q3-base, pkgsrc-2022Q3, pkgsrc-2022Q2-base, pkgsrc-2022Q2
Changes since 1.13: +2 -2 lines
Diff to previous 1.13 (colored)

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.

Revision 1.13 / (download) - annotate - [select for diffs], Thu Mar 31 08:43:02 2022 UTC (22 months, 4 weeks ago) by adam
Branch: MAIN
Changes since 1.12: +2 -3 lines
Diff to previous 1.12 (colored)

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„ŗ—’ 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„ŗ—’ 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.

Revision 1.12 / (download) - annotate - [select for diffs], Tue Jan 4 20:53:48 2022 UTC (2 years, 1 month ago) by wiz
Branch: MAIN
CVS Tags: pkgsrc-2022Q1-base, pkgsrc-2022Q1
Changes since 1.11: +2 -1 lines
Diff to previous 1.11 (colored)

*: bump PKGREVISION for egg.mk users

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

Revision 1.11 / (download) - annotate - [select for diffs], Sun Oct 31 09:21:37 2021 UTC (2 years, 3 months ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2021Q4-base, pkgsrc-2021Q4
Changes since 1.10: +8 -2 lines
Diff to previous 1.10 (colored)

py-wrapt: updated to 1.13.3

Version 1.13.3

New Features

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

Revision 1.10 / (download) - annotate - [select for diffs], Wed Oct 13 06:58:32 2021 UTC (2 years, 4 months ago) by adam
Branch: MAIN
Changes since 1.9: +2 -2 lines
Diff to previous 1.9 (colored)

py-wrapt: updated to 1.13.2

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

Revision 1.9 / (download) - annotate - [select for diffs], Mon Oct 11 18:02:12 2021 UTC (2 years, 4 months ago) by adam
Branch: MAIN
Changes since 1.8: +3 -3 lines
Diff to previous 1.8 (colored)

py-wrapt: updated to 1.13.1

Version 1.13.1

Bugs Fixed

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

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

Revision 1.8 / (download) - annotate - [select for diffs], Tue Mar 17 20:05:53 2020 UTC (3 years, 11 months ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2021Q3-base, pkgsrc-2021Q3, pkgsrc-2021Q2-base, pkgsrc-2021Q2, pkgsrc-2021Q1-base, pkgsrc-2021Q1, pkgsrc-2020Q4-base, pkgsrc-2020Q4, pkgsrc-2020Q3-base, pkgsrc-2020Q3, pkgsrc-2020Q2-base, pkgsrc-2020Q2, pkgsrc-2020Q1-base, pkgsrc-2020Q1
Changes since 1.7: +2 -2 lines
Diff to previous 1.7 (colored)

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.

Revision 1.7 / (download) - annotate - [select for diffs], Tue Jun 18 08:00:34 2019 UTC (4 years, 8 months ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2019Q4-base, pkgsrc-2019Q4, pkgsrc-2019Q3-base, pkgsrc-2019Q3, pkgsrc-2019Q2-base, pkgsrc-2019Q2
Changes since 1.6: +2 -2 lines
Diff to previous 1.6 (colored)

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.

Revision 1.6 / (download) - annotate - [select for diffs], Mon Jan 21 10:31:16 2019 UTC (5 years, 1 month ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2019Q1-base, pkgsrc-2019Q1
Changes since 1.5: +2 -2 lines
Diff to previous 1.5 (colored)

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.

Revision 1.5 / (download) - annotate - [select for diffs], Wed Aug 16 18:07:31 2017 UTC (6 years, 6 months ago) by adam
Branch: MAIN
CVS Tags: pkgsrc-2018Q4-base, pkgsrc-2018Q4, pkgsrc-2018Q3-base, pkgsrc-2018Q3, pkgsrc-2018Q2-base, pkgsrc-2018Q2, pkgsrc-2018Q1-base, pkgsrc-2018Q1, pkgsrc-2017Q4-base, pkgsrc-2017Q4, pkgsrc-2017Q3-base, pkgsrc-2017Q3
Changes since 1.4: +2 -2 lines
Diff to previous 1.4 (colored)

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.

Revision 1.4 / (download) - annotate - [select for diffs], Sun Jul 30 22:32:16 2017 UTC (6 years, 7 months ago) by wiz
Branch: MAIN
Changes since 1.3: +2 -2 lines
Diff to previous 1.3 (colored)

Switch github HOMEPAGEs to https.

Revision 1.3 / (download) - annotate - [select for diffs], Sun Jul 16 19:55:03 2017 UTC (6 years, 7 months ago) by adam
Branch: MAIN
Changes since 1.2: +2 -2 lines
Diff to previous 1.2 (colored)

Added 'python' to CATEGORIES

Revision 1.2 / (download) - annotate - [select for diffs], Wed Jun 7 14:42:26 2017 UTC (6 years, 8 months ago) by ryoon
Branch: MAIN
CVS Tags: pkgsrc-2017Q2-base, pkgsrc-2017Q2
Changes since 1.1: +2 -2 lines
Diff to previous 1.1 (colored)

Fix build with Perl 5.26.0

Revision 1.1 / (download) - annotate - [select for diffs], Thu May 5 11:15:33 2016 UTC (7 years, 9 months ago) by richard
Branch: MAIN
CVS Tags: pkgsrc-2017Q1-base, pkgsrc-2017Q1, pkgsrc-2016Q4-base, pkgsrc-2016Q4, pkgsrc-2016Q3-base, pkgsrc-2016Q3, pkgsrc-2016Q2-base, pkgsrc-2016Q2

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.

This form allows you to request diff's between any two revisions of a file. You may select a symbolic revision name using the selection box or you may type in a numeric name using the type-in text box.




CVSweb <webmaster@jp.NetBSD.org>