Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scheduled biweekly dependency update for week 06 #696

Merged
merged 12 commits into from
Feb 8, 2023

Conversation

pyup-bot
Copy link
Collaborator

@pyup-bot pyup-bot commented Feb 6, 2023

Update numpy from 1.24.1 to 1.24.2.

The bot wasn't able to find a changelog for this release. Got an idea?

Links

Update pandas from 1.5.2 to 1.5.3.

The bot wasn't able to find a changelog for this release. Got an idea?

Links

Update astroid from 2.11.7 to 2.14.1.

The bot wasn't able to find a changelog for this release. Got an idea?

Links

Update zipp from 3.12.0 to 3.12.1.

Changelog

3.12.1

=======

* gh-101566: In ``CompleteDirs``, override ``ZipFile.getinfo``
to supply a ``ZipInfo`` for implied dirs.
Links

Update wrapt from 1.14.1 to 1.14.1.

Changelog

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.

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.

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.

1.11.2

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

**Bugs Fixed**

* Fix possible crash when garbage collection kicks in when invoking a
destructor of wrapped object.

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.

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.

**Features Changed**

* Dropped support for Python 2.6 and 3.3.

* If ``copy.copy()`` or ``copy.deepcopy()`` is used on an instance of the
``ObjectProxy`` class, a ``NotImplementedError`` exception is raised, with
a message indicating that the object proxy must implement the
``__copy__()`` or ``__deepcopy__()`` method. This is in place of the
default ``TypeError`` exception with message indicating a pickle error.

* If ``pickle.dump()`` or ``pickle.dumps()`` is used on an instance of the
``ObjectProxy`` class, a ``NotImplementedError`` exception is raised, with
a message indicating that the object proxy must implement the
``__reduce_ex__()`` method. This is in place of the default ``TypeError``
exception with message indicating a pickle error.

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.

1.10.10

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

**Features Changed**

* Added back missing description and categorisations when releasing to PyPi.

1.10.9

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

**Bugs Fixed**

* Code for ``inspect.getargspec()`` when using Python 2.6 was missing
import of ``sys`` module.

1.10.8

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

**Bugs Fixed**

* Ensure that ``inspect.getargspec()`` is only used with Python 2.6 where
required, as function has been removed in Python 3.6.

1.10.7

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

**Bugs Fixed**

* The mod operator '%' was being incorrectly proxied in Python variant of
object proxy to the xor operator '^'.

1.10.6

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

**Bugs Fixed**

* Registration of post import hook would fail with an exception if
registered after another import hook for the same target module had been
registered and the target module also imported.

**New Features**

* Support for testing with Travis CI added to repository.

1.10.5

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

**Bugs Fixed**

* Post import hook discovery was not working correctly where multiple
target modules were registered in the same entry point list. Only the
callback for the last would be called regardless of the target module.

* If a ``WeakFunctionProxy`` wrapper was used around a method of a class
which was decorated using a wrapt decorator, the decorator wasn't being
invoked when the method was called via the weakref proxy.

**Features Changed**

* The ``register_post_import_hook()`` function, modelled after the
function of the same name in PEP-369 has been extended to allow a string
name to be supplied for the import hook. This needs to be of the form
``module::function`` and will result in an import hook proxy being used
which will only load and call the function of the specified moduled when
the import hook is required. This avoids needing to load the code needed
to operate on the target module unless required.

1.10.4

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

**Bugs Fixed**

* Fixup botched package version number from 1.10.3 release.

1.10.3

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

**Bugs Fixed**

* Post import hook discovery from third party modules declared via
``setuptools`` entry points was failing due to typo in temporary variable
name. Also added the ``discover_post_import_hooks()`` to the public API
as was missing.

**Features Changed**

* To ensure parity between pure Python and C extension variants of the
``ObjectProxy`` class, allow the ``__wrapped__`` attribute to be set
in a derived class when the ``ObjectProxy.__init__()`` method hasn't
been called.

1.10.2

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

**Bugs Fixed**

* When creating a derived ``ObjectProxy``, if the base class ``__init__()``
method wasn't called and the ``__wrapped__`` attribute was accessed,
in the pure Python implementation a recursive call of ``__getattr__()``
would occur and the maximum stack depth would be reached and an exception
raised.

* When creating a derived ``ObjectProxy``, if the base class ``__init__()``
method wasn't called, in the C extension implementation, if that instance
was then used in a binary arithmetic operation the process would crash.

1.10.1

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

**Bugs Fixed**

* When using ``FunctionWrapper`` around a method of an existing instance of
a class, rather than on the type, then a memory leak could occur in two
different scenarios.

The first issue was that wrapping a method on an instance of a class was
causing an unwanted reference to the class meaning that if the class type
was transient, such as it is being created inside of a function call, the
type object would leak.

The second issue was that wrapping a method on an instance of a class and
then calling the method was causing an unwanted reference to the instance
meaning that if the instance was transient, it would leak.

This was only occurring when the C extension component for the
``wrapt`` module was being used.

1.10.0

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

**New Features**

* When specifying an adapter for a decorator, it is now possible to pass
in, in addition to passing in a callable, a tuple of the form which
is returned by ``inspect.getargspec()``, or a string of the form which
is returned by ``inspect.formatargspec()``. In these two cases the
decorator will automatically compile a stub function to use as the
adapter. This eliminates the need for a caller to generate the stub
function if generating the signature on the fly.

::

   def argspec_factory(wrapped):
       argspec = inspect.getargspec(wrapped)

       args = argspec.args[1:]
       defaults = argspec.defaults and argspec.defaults[-len(argspec.args):]

       return inspect.ArgSpec(args, argspec.varargs,
               argspec.keywords, defaults)

   def session(wrapped):
       wrapt.decorator(adapter=argspec_factory(wrapped))
       def _session(wrapped, instance, args, kwargs):
           with transaction() as session:
               return wrapped(session, *args, **kwargs)

       return _session(wrapped)

This mechanism and the original mechanism to pass a function, meant
that the adapter function had to be created in advance. If the adapter
needed to be generated on demand for the specific function to be
wrapped, then it would have been necessary to use a closure around
the definition of the decorator as above, such that the generator could
be passed in.

As a convenience, instead of using such a closure, it is also now
possible to write:

::

   def argspec_factory(wrapped):
       argspec = inspect.getargspec(wrapped)

       args = argspec.args[1:]
       defaults = argspec.defaults and argspec.defaults[-len(argspec.args):]

       return inspect.ArgSpec(args, argspec.varargs,
               argspec.keywords, defaults)

   wrapt.decorator(adapter=wrapt.adapter_factory(argspec_factory))
   def _session(wrapped, instance, args, kwargs):
       with transaction() as session:
           return wrapped(session, *args, **kwargs)

The result of ``wrapt.adapter_factory()`` will be recognised as indicating
that the creation of the adapter is to be deferred until the decorator is
being applied to a function. The factory function for generating the
adapter function or specification on demand will be passed the function
being wrapped by the decorator.

If wishing to create a library of routines for generating adapter
functions or specifications dynamically, then you can do so by creating
classes which derive from ``wrapt.AdapterFactory`` as that is the type
which is recognised as indicating lazy evaluation of the adapter
function. For example, ``wrapt.adapter_factory()`` is itself implemented
as:

::

   class DelegatedAdapterFactory(wrapt.AdapterFactory):
       def __init__(self, factory):
           super(DelegatedAdapterFactory, self).__init__()
           self.factory = factory
       def __call__(self, wrapped):
           return self.factory(wrapped)

   adapter_factory = DelegatedAdapterFactory

**Bugs Fixed**

* The ``inspect.signature()`` function was only added in Python 3.3.
Use fallback when doesn't exist and on Python 3.2 or earlier Python 3
versions.

Note that testing is only performed for Python 3.3+, so it isn't
actually known if the ``wrapt`` package works on Python 3.2.

1.9.0

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

**Features Changed**

* When using ``wrapt.wrap_object()``, it is now possible to pass an
arbitrary object in addition to a module object, or a string name
identifying a module. Similar for underlying ``wrapt.resolve_path()``
function.

**Bugs Fixed**

* It is necessary to proxy the special ``__weakref__`` attribute in the
pure Python object proxy else using ``inspect.getmembers()`` on a
decorator class will fail.

* The ``FunctionWrapper`` class was not passing through the instance
correctly to the wrapper function when it was applied to a method of an
existing instance of a class.

* The ``FunctionWrapper`` was not always working when applied around a
method of a class type by accessing the method to be wrapped using
``getattr()``. Instead it is necessary to access the original unbound
method from the class ``__dict__``. Updated the ``FunctionWrapper`` to
work better in such situations, but also modify ``resolve_path()`` to
always grab the class method from the class ``__dict__`` when wrapping
methods using ``wrapt.wrap_object()`` so wrapping is more predictable.
When doing monkey patching ``wrapt.wrap_object()`` should always be
used to ensure correct operation.

* The ``AttributeWrapper`` class used internally to the function
``wrap_object_attribute()`` had wrongly named the ``__delete__`` method
for the descriptor as ``__del__``.

1.8.0

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

**Features Changed**

* Previously using wrapt.decorator on a class type didn't really yield
anything which was practically useful. This is now changed and when
applied to a class an instance of the class will be automatically
created to be used as the decorator wrapper function. The requirement
for this is that the __call__() method be specified in the style as
would be done for the decorator wrapper function.

::

   wrapt.decorator
   class mydecoratorclass(object):
       def __init__(self, arg=None):
           self.arg = arg
       def __call__(self, wrapped, instance, args, kwargs):
           return wrapped(*args, **kwargs)

   mydecoratorclass
   def function():
       pass

If the resulting decorator class is to be used with no arguments, the
__init__() method of the class must have all default arguments. These
arguments can be optionally supplied though, by using keyword arguments
to the resulting decorator when applied to the function to be decorated.

::

   mydecoratorclass(arg=1)
   def function():
       pass

1.7.0

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

**New Features**

* Provide wrapt.getcallargs() for determining how arguments mapped to a
wrapped function. For Python 2.7 this is actually inspect.getcallargs()
with a local copy being used in the case of Python 2.6.

* Added wrapt.wrap_object_attribute() as a way of wrapping or otherwise
modifying the result of trying to access the attribute of an object
instance. It works by adding a data descriptor with the same name as
the attribute, to the class type, allowing reading of the attribute
to be intercepted. It does not affect updates to or deletion of the
attribute.

**Bugs Fixed**

* Need to explicitly proxy special methods __bytes__(), __reversed__()
and __round__() as they are only looked up on the class type and not
the instance, so can't rely on __getattr__() fallback.

* Raise more appropriate TypeError, with corresponding message, rather
than IndexError, when a decorated instance or class method is called via
the class but the required 1st argument of the instance or class is not
supplied.

1.6.0

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

**Bugs Fixed**

* The ObjectProxy class would return that the __call__() method existed
even though the wrapped object didn't have one. Similarly, callable()
would always return True even if the wrapped object was not callable.

This resulted due to the existence of the __call__() method on the
wrapper, required to support the possibility that the wrapped object
may be called via the proxy object even if it may not turn out that
the wrapped object was callable.

Because checking for the existence of a __call__() method or using
callable() can sometimes be used to indirectly infer the type of an
object, this could cause issues. To ensure that this now doesn't
occur, the ability to call a wrapped object via the proxy object has
been removed from ObjectProxy. Instead, a new class CallableObjectProxy
is now provided, with it being necessary to make a conscious choice as
to which should be used based on whether the object to be wrapped is
in fact callable.

Note that neither before this change, or with the introduction of the
class CallableObjectProxy, does the object proxy perform binding. If
binding behaviour is required it still needs to be implemented
explicitly to match the specific requirements of the use case.
Alternatively, the FunctionWrapper class should be used which does
implement binding, but also enforces a wrapper mechanism for
manipulating what happens at the time of the call.

1.5.1

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

**Bugs Fixed**

* Instance method locking for the synchronized decorator was not correctly
locking on the instance but the class, if a synchronized class method
had been called prior to the synchronized instance method.

1.5.0

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

**New Features**

* Enhanced wrapt.transient_function_wrapper so it can be applied to
instance methods and class methods with the self/cls argument being
supplied correctly. This allows instance and class methods to be used for
this type of decorator, with the instance or class type being able to
be used to hold any state required for the decorator.

**Bugs Fixed**

* If the wrong details for a function to be patched was given to the
decorator wrapt.transient_function_wrapper, the exception indicating
this was being incorrectly swallowed up and mutating to a different
more obscure error about local variable being access before being set.

1.4.2

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

**Bugs Fixed**

* A process could crash if the C extension module was used and when using
the ObjectProxy class a reference count cycle was created that required
the Python garbage collector to kick in to break the cycle. This was
occurring as the C extension had not implemented GC support in the
ObjectProxy class correctly.

1.4.1

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

**Bugs Fixed**

* Overriding __wrapped__ attribute directly on any wrapper more than once
could cause corruption of memory due to incorrect reference count
decrement.

1.4.0

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

**New Features**

* Enhanced wrapt.decorator and wrapt.function_wrapper so they can be
applied to instance methods and class methods with the self/cls argument
being supplied correctly. This allows instance and class methods to be
used as decorators, with the instance or class type being able to be used
to hold any state required for the decorator.

**Bugs Fixed**

* Fixed process crash in extension when the wrapped object passed as first
argument to FunctionWrapper did not have a tp_descr_get callback for the
type at C code level. Now raised an AttributeError exception in line with
what Python implementation does.

1.3.1

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

**Bugs Fixed**

* The discover_post_import_hooks() function had not been added to the
top level wrapt module.

1.3.0

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

**New Features**

* Added a transient_function_wrapper decorator for applying a wrapper
function around a target function only for the life of a single function
call. The decorator is useful for performing mocking or pass through
data validation/modification when doing unit testing of packages.

1.2.1

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

**Bugs Fixed**

* In C implementation, not dealing with unbound method type creation
properly which would cause later problems when calling instance method
via the class type in certain circumstances. Introduced problem in 1.2.0.

* Eliminated compiler warnings due to missing casts in C implementation.

1.2.0

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

**New Features**

* Added an 'enabled' option to decorator and FunctionWrapper which can
be provided a boolean, or a function returning a boolean to allow the
work of the decorator to be disabled dynamically. When a boolean, is
used for decorator, the wrapper will not even be applied if 'enabled'
is False. If a function, then will be called prior to wrapper being
called and if returns False, then original wrapped function called
directly rather than the wrapper being called.

* Added in an implementation of a post import hook mechanism in line with
that described in PEP 369.

* Added in helper functions specifically designed to assist in performing
monkey patching of existing code.

**Features Changed**

* Collapsed functionality of _BoundMethodWrapper into _BoundFunctionWrapper
and renamed the latter to BoundFunctionWrapper. If deriving from the
FunctionWrapper class and needing to override the type of the bound
wrapper, the class attribute ``__bound_function_wrapper__`` should be set
in the derived FunctionWrapper class to the replacement type.

**Bugs Fixed**

* When creating a custom proxy by deriving from ObjectProxy and the custom
proxy needed to override __getattr__(), it was not possible to called the
base class ObjectProxy.__getattr__() when the C implementation of
ObjectProxy was being used. The derived class __getattr__() could also
get ignored.

* Using inspect.getargspec() now works correctly on bound methods when an
adapter function can be provided to decorator.

1.1.3

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

**New Features**

* Added a _self_parent attribute to FunctionWrapper and bound variants.
For the FunctionWrapper the value will always be None. In the case of the
bound variants of the function wrapper, the attribute will refer back
to the unbound FunctionWrapper instance. This can be used to get a back
reference to the parent to access or cache data against the persistent
function wrapper, the bound wrappers often being transient and only
existing for the single call.

**Improvements**

* Use interned strings to optimise name comparisons in the setattro()
method of the C implementation of the object proxy.

**Bugs Fixed**

* The pypy interpreter is missing operator.__index__() so proxying of that
method in the object proxy would fail. This is a bug in pypy which is
being addressed. Use operator.index() instead which pypy does provide
and which also exists for CPython.

* The pure Python implementation allowed the __wrapped__ attribute to be
deleted which could cause problems. Now raise a TypeError exception.

* The C implementation of the object proxy would crash if an attempt was
made to delete the __wrapped__ attribute from the object proxy. Now raise a
TypeError exception.

1.1.2

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

**Improvements**

* Reduced performance overhead from previous versions. Most notable in the
C implementation. Benchmark figures have been updated in documentation.

1.1.1

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

**Bugs Fixed**

* Python object memory leak was occurring due to incorrect increment of
object reference count in C implementation of object proxy when an
instance method was called via the class and the instance passed in
explicitly.

* In place operators in pure Python object proxy for __idiv__ and
__itruediv__ were not replacing the wrapped object with the result
of the operation on the wrapped object.

* In place operators in C implementation of Python object proxy were
not replacing the wrapped object with the result of the operation on the
wrapped object.

1.1.0

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

**New Features**

* Added a synchronized decorator for performing thread mutex locking on
functions, object instances or classes. This is the same decorator as
covered as an example in the wrapt documentation.

* Added a WeakFunctionProxy class which can wrap references to instance
methods as well as normal functions.

* Exposed from the C extension the classes _FunctionWrapperBase,
_BoundFunctionWrapper and _BoundMethodWrapper so that it is possible to
create new variants of FunctionWrapper in pure Python code.

**Bugs Fixed**

* When deriving from ObjectProxy, and the C extension variant
was being used, if a derived class overrode __new__() and tried to access
attributes of the ObjectProxy created using the base class __new__()
before __init__() was called, then an exception would be raised
indicating that the 'wrapper has not been initialised'.

* When deriving from ObjectProxy, and the C extension variant
was being used, if a derived class __init__() attempted to update
attributes, even the special '_self_' attributed before calling the base
class __init__() method, then an exception would be raised indicating
that the 'wrapper has not been initialised'.

1.0.0

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

Initial release.
Links

Update pytz from 2022.7.1 to 2022.7.1.

The bot wasn't able to find a changelog for this release. Got an idea?

Links

Update pythonnet from 3.0.1 to 3.0.1.

Changelog

2.4.0

Added

-   Added support for embedding python into dotnet core 2.0 (NetStandard 2.0)
-   Added new build system (pythonnet.15.sln) based on dotnetcore-sdk/xplat(crossplatform msbuild).
 Currently there two side-by-side build systems that produces the same output (net40) from the same sources.
 After a some transition time, current (mono/ msbuild 14.0) build system will be removed.
-   NUnit upgraded to 3.7 (eliminates travis-ci random bug)
-   Added C `PythonEngine.AddShutdownHandler` to help client code clean up on shutdown.
-   Added `clr.GetClrType` ([432][i432])([433][p433])
-   Allowed passing `None` for nullable args ([460][p460])
-   Added keyword arguments based on C syntax for calling CPython methods ([461][p461])
-   Catches exceptions thrown in C iterators (yield returns) and rethrows them in python ([475][i475])([693][p693])
-   Implemented GetDynamicMemberNames() for PyObject to allow dynamic object members to be visible in the debugger ([443][i443])([690][p690])
-   Incorporated reference-style links to issues and pull requests in the CHANGELOG ([608][i608])
-   Added PyObject finalizer support, Python objects referred by C can be auto collect now ([692][p692]).
-   Added detailed comments about aproaches and dangers to handle multi-app-domains ([625][p625])
-   Python 3.7 support, builds and testing added. Defaults changed from Python 3.6 to 3.7 ([698][p698])
-   Added support for C types to provide `__repr__` ([680][p680])

Changed

-   PythonException included C call stack
-   Reattach python exception traceback information (545)
-   PythonEngine.Intialize will now call `Py_InitializeEx` with a default value of 0, so signals will not be configured by default on embedding. This is different from the previous behaviour, where `Py_Initialize` was called instead, which sets initSigs to 1. ([449][i449])
-   Refactored MethodBinder.Bind in preparation to make it extensible (829)
-   Look for installed Windows 10 sdk's during installation instead of relying on specific versions.
-   Remove `LoadLibrary` call. ([880][p880])

Fixed

-   Fixed secondary PythonEngine.Initialize call, all sensitive static variables now reseted.
 This is a hidden bug. Once python cleaning up enough memory, objects from previous engine run becomes corrupted. ([534][p534])
-   Fixed Visual Studio 2017 compat ([434][i434]) for setup.py
-   Fixed crashes when integrating pythonnet in Unity3d ([714][i714]),
 related to unloading the Application Domain
-   Fixed interop methods with Py_ssize_t. NetCoreApp 2.0 is more sensitive than net40 and requires this fix. ([531][p531])
-   Fixed crash on exit of the Python interpreter if a python class
 derived from a .NET class has a `__namespace__` or `__assembly__`
 attribute ([481][i481])
-   Fixed conversion of 'float' and 'double' values ([486][i486])
-   Fixed 'clrmethod' for python 2 ([492][i492])
-   Fixed double calling of constructor when deriving from .NET class ([495][i495])
-   Fixed `clr.GetClrType` when iterating over `System` members ([607][p607])
-   Fixed `LockRecursionException` when loading assemblies ([627][i627])
-   Fixed errors breaking .NET Remoting on method invoke ([276][i276])
-   Fixed PyObject.GetHashCode ([676][i676])
-   Fix memory leaks due to spurious handle incrementation ([691][i691])
-   Fix spurious assembly loading exceptions from private types ([703][i703])
-   Fix inheritance of non-abstract base methods ([755][i755])

2.2.0

Added

-   Python 3.6 support ([310][p310])
-   Added `__version__` to module ([312][p312])
-   Added `conda` recipe ([281][p281])
-   Nuget update on build ([268][p268])
-   Added `__cause__` attribute on exception ([287][p287])

Changed

-   License to MIT ([314][p314])
-   Project clean-up ([320][p320])
-   Refactor `if` directives
-   Rename Decref/Incref to XDecref/XIncre ([275][p275])
-   Remove printing if Decref is called with NULL ([275][p275])

Removed

-   Python 2.6 support ([270][i270])
-   Python 3.2 support ([270][i270])

Fixed

-   Fixed `isinstance` refcount_leak ([273][p273])
-   Comparison Operators ([294][p294])
-   Improved Linux support ([300][p300])
-   Exception pickling ([286][p286])

2.0.0alpha.2

Changed

-   First work on Python 2.5 compatibility. The destination version can be
 set by defining PYTHON24 or PYTHON25. Python 2.6 compatibility is in
 work.

-   Added VS 2005 solution and project files including a UnitTest
 configuration which runs the unit test suite.

-   Enhanced unit test suite. All test cases are combined in a single
 test suite now.

-   Fixed bugs in generics support for all Python versions.

-   Fixed exception bugs for Python 2.5+. When compiled for Python 2.5+ all
 managed exceptions are based on Python's `exceptions.Exception` class.

-   Added deprecation warnings for importing from `CLR.*` and the CLR module.

-   Implemented support for methods with variable arguments
 `spam(params object[] egg)`

-   Fixed Mono support by adding a custom marshaler for UCS-4 unicode,
 fixing a some ref counter bugs and creating a new makefile.mono.

-   Added a standard python extension to load the clr environment.
 The `src/monoclr/` directory contains additional sample code like a
 Python binary linked against `libpython2.x.so` and some example code
 how to embed Mono and PythonNet in a C application.

-   Added yet another python prompt. This time it's a C application that
 embedds both Python and Mono. It may be useful as an example app for
 others and I need it to debug a nasty bug.

-   Implemented `ModuleFunctionAttribute` and added
 `ForbidPythonThreadsAttribute`. The latter is required for module
 functions which invoke Python methods.

-   Added `clr.setPreload()`, `clr.getPreload()`,
 `clr.AddReference("assembly name")`, `clr.FindAssembly("name")`
 and `clr.ListAssemblies(verbose)`. Automatic preloading can be enabled
 with clr.setPreload/True). Preloading is automatically enabled for
 interactive Python shells and disabled in all other cases.

-   New Makefile that works for Windows and Mono and autodetects the Python
 version and UCS 2/4 setting.

-   Added code for Python 2.3. PythonNet can be build for Python 2.3 again
 but it is not fully supported.

-   Changed the PythonException.Message value so it displays the name of
 the exception class `Exception` instead of its representation
 `<type 'exceptions.Exception'>`.

-   Added `Python.Runtime.dll.config`.

2.0.0alpha.1

Changed

-   Moved the Python for .NET project to Sourceforge and moved version
 control to Subversion.

-   Removed `CallConvCdecl` attributes and the IL hack that they supported.
 .NET 2.x now supports `UnmanagedFunctionPointer`, which does the right
 thing without the hackery required in 1.x. This removes a dependency
 on ILASM to build the package and better supports Mono (in theory).

-   Refactored import and assembly management machinery. The old `CLR.`
 syntax for import is deprecated, but still supported until 3.x. The
 recommended style now is to use `from System import xxx`, etc. We
 also now support `from X import *` correctly.

-   Implemented a (lowercase) `clr` module to match IronPython for code
 compatibility. Methods of this module should be used to explicitly
 load assemblies. Implicit (name-based) assembly loading will still
 work until 3.x, but it is deprecated.

-   Implemented support for generic types and generic methods using the
 same patterns and syntax as IronPython. See the documentation for
 usage details.

-   Many small and large performance improvements, switched to generic
 collections for some internals, better algorithms for assembly
 scanning, etc.

-   Fixed an unboxing issue in generated delegate implementation code
 that affected delegates that return value types.

1.0.0

[i714]: https://github.com/pythonnet/pythonnet/issues/714
[i608]: https://github.com/pythonnet/pythonnet/issues/608
[i443]: https://github.com/pythonnet/pythonnet/issues/443
[p690]: https://github.com/pythonnet/pythonnet/pull/690
[i475]: https://github.com/pythonnet/pythonnet/issues/475
[p693]: https://github.com/pythonnet/pythonnet/pull/693
[i432]: https://github.com/pythonnet/pythonnet/issues/432
[p433]: https://github.com/pythonnet/pythonnet/pull/433
[p460]: https://github.com/pythonnet/pythonnet/pull/460
[p461]: https://github.com/pythonnet/pythonnet/pull/461
[p433]: https://github.com/pythonnet/pythonnet/pull/433
[i434]: https://github.com/pythonnet/pythonnet/issues/434
[i481]: https://github.com/pythonnet/pythonnet/issues/481
[i486]: https://github.com/pythonnet/pythonnet/issues/486
[i492]: https://github.com/pythonnet/pythonnet/issues/492
[i495]: https://github.com/pythonnet/pythonnet/issues/495
[p607]: https://github.com/pythonnet/pythonnet/pull/607
[i627]: https://github.com/pythonnet/pythonnet/issues/627
[i276]: https://github.com/pythonnet/pythonnet/issues/276
[i676]: https://github.com/pythonnet/pythonnet/issues/676
[p345]: https://github.com/pythonnet/pythonnet/pull/345
[p347]: https://github.com/pythonnet/pythonnet/pull/347
[p349]: https://github.com/pythonnet/pythonnet/pull/349
[i224]: https://github.com/pythonnet/pythonnet/issues/224
[p353]: https://github.com/pythonnet/pythonnet/pull/353
[p391]: https://github.com/pythonnet/pythonnet/pull/391
[p346]: https://github.com/pythonnet/pythonnet/pull/346
[p384]: https://github.com/pythonnet/pythonnet/pull/384
[i383]: https://github.com/pythonnet/pythonnet/issues/383
[p386]: https://github.com/pythonnet/pythonnet/pull/386
[i370]: https://github.com/pythonnet/pythonnet/issues/370
[p373]: https://github.com/pythonnet/pythonnet/pull/373
[i390]: https://github.com/pythonnet/pythonnet/issues/390
[i319]: https://github.com/pythonnet/pythonnet/issues/319
[p398]: https://github.com/pythonnet/pythonnet/pull/398
[p345]: https://github.com/pythonnet/pythonnet/pull/345
[p389]: https://github.com/pythonnet/pythonnet/pull/389
[p407]: https://github.com/pythonnet/pythonnet/pull/407
[i322]: https://github.com/pythonnet/pythonnet/issues/322
[i66]: https://github.com/pythonnet/pythonnet/issues/66
[p329]: https://github.com/pythonnet/pythonnet/pull/329
[p337]: https://github.com/pythonnet/pythonnet/pull/337
[p339]: https://github.com/pythonnet/pythonnet/pull/339
[p369]: https://github.com/pythonnet/pythonnet/pull/369
[p368]: https://github.com/pythonnet/pythonnet/pull/368
[p341]: https://github.com/pythonnet/pythonnet/pull/341
[p353]: https://github.com/pythonnet/pythonnet/pull/353
[p371]: https://github.com/pythonnet/pythonnet/pull/371
[p345]: https://github.com/pythonnet/pythonnet/pull/345
[i362]: https://github.com/pythonnet/pythonnet/issues/362
[i401]: https://github.com/pythonnet/pythonnet/issues/401
[i262]: https://github.com/pythonnet/pythonnet/issues/262
[p343]: https://github.com/pythonnet/pythonnet/pull/343
[p365]: https://github.com/pythonnet/pythonnet/pull/365
[i203]: https://github.com/pythonnet/pythonnet/issues/203
[p377]: https://github.com/pythonnet/pythonnet/pull/377
[p398]: https://github.com/pythonnet/pythonnet/pull/398
[p400]: https://github.com/pythonnet/pythonnet/pull/400
[i397]: https://github.com/pythonnet/pythonnet/issues/397
[p399]: https://github.com/pythonnet/pythonnet/pull/399
[i120]: https://github.com/pythonnet/pythonnet/issues/120
[i413]: https://github.com/pythonnet/pythonnet/issues/413
[i179]: https://github.com/pythonnet/pythonnet/issues/179
[i414]: https://github.com/pythonnet/pythonnet/issues/414
[p415]: https://github.com/pythonnet/pythonnet/pull/415
[p329]: https://github.com/pythonnet/pythonnet/pull/329
[p360]: https://github.com/pythonnet/pythonnet/pull/360
[i417]: https://github.com/pythonnet/pythonnet/issues/417
[i336]: https://github.com/pythonnet/pythonnet/issues/336
[p310]: https://github.com/pythonnet/pythonnet/pull/310
[p312]: https://github.com/pythonnet/pythonnet/pull/312
[p281]: https://github.com/pythonnet/pythonnet/pull/281
[p268]: https://github.com/pythonnet/pythonnet/pull/268
[p287]: https://github.com/pythonnet/pythonnet/pull/287
[p314]: https://github.com/pythonnet/pythonnet/pull/314
[p320]: https://github.com/pythonnet/pythonnet/pull/320
[p275]: https://github.com/pythonnet/pythonnet/pull/275
[i270]: https://github.com/pythonnet/pythonnet/issues/270
[p273]: https://github.com/pythonnet/pythonnet/pull/273
[p294]: https://github.com/pythonnet/pythonnet/pull/294
[p300]: https://github.com/pythonnet/pythonnet/pull/300
[p286]: https://github.com/pythonnet/pythonnet/pull/286
[p219]: https://github.com/pythonnet/pythonnet/pull/219
[p208]: https://github.com/pythonnet/pythonnet/pull/208
[p206]: https://github.com/pythonnet/pythonnet/pull/206
[p233]: https://github.com/pythonnet/pythonnet/pull/233
[p219]: https://github.com/pythonnet/pythonnet/pull/219
[p250]: https://github.com/pythonnet/pythonnet/pull/250
[p225]: https://github.com/pythonnet/pythonnet/pull/225
[p78]: https://github.com/pythonnet/pythonnet/pull/78
[p163]: https://github.com/pythonnet/pythonnet/pull/163
[p625]: https://github.com/pythonnet/pythonnet/pull/625
[i131]: https://github.com/pythonnet/pythonnet/issues/131
[p531]: https://github.com/pythonnet/pythonnet/pull/531
[i755]: https://github.com/pythonnet/pythonnet/pull/755
[p534]: https://github.com/pythonnet/pythonnet/pull/534
[i449]: https://github.com/pythonnet/pythonnet/issues/449
[i1342]: https://github.com/pythonnet/pythonnet/issues/1342
[i238]: https://github.com/pythonnet/pythonnet/issues/238
[i1481]: https://github.com/pythonnet/pythonnet/issues/1481
[i1672]: https://github.com/pythonnet/pythonnet/pull/1672

1.0.0rc.2

Changed

-   Changed some uses of Finalize as a static method name that confused the
 Mono compiler and people reading the code. Note that this may be a
 breaking change if anyone was calling `PythonEngine.Finalize()`. If so,
 you should now use `PythonEngine.Shutdown()`.

-   Tweaked assembly lookup to ensure that assemblies can be found in the
 current working directory, even after changing directories using things
 like `os.chdir()` from Python.

-   Fixed some incorrect finalizers (thanks to Greg Chapman for the report)
 that may have caused some threading oddities.

-   Tweaked support for out and ref parameters. If a method has a return
 type of void and a single ref or out parameter, that parameter will be
 returned as the result of the method. This matches the current behavior
 of IronPython and makes it more likely that code can be moved between
 Python for .NET and IP in the future.

-   Refactored part of the assembly manager to remove a potential case of
 thread-deadlock in multi-threaded applications.

-   Added a `__str__` method to managed exceptions that returns the Message
 attribute of the exception and the StackTrace (if available).

1.0.0rc.1

Changed

-   Implemented a workaround for the fact that exceptions cannot be new-style
 classes in the CPython interpreter. Managed exceptions can now be raised
 and caught naturally from Python (hooray!)

-   Implemented support for invoking methods with out and ref parameters.
 Because there is no real equivalent to these in Python, methods that
 have out or ref parameters will return a tuple. The tuple will contain
 the result of the method as its first item, followed by out parameter
 values in the order of their declaration in the method signature.

-   Fixed a refcount problem that caused a crash when CLR was imported in
 an existing installed Python interpreter.

-   Added an automatic conversion from Python strings to `byte[]`. This makes
 it easier to pass `byte[]` data to managed methods (or set properties,
 etc.) as a Python string without having to write explicit conversion
 code. Also works for sbyte arrays. Note that `byte` and `sbyte` arrays
 returned from managed methods or obtained from properties or fields
 do _not_ get converted to Python strings - they remain instances of
 `Byte[]` or `SByte[]`.

-   Added conversion of generic Python sequences to object arrays when
 appropriate (thanks to Mackenzie Straight for the patch).

-   Added a bit of cautionary documentation for embedders, focused on
 correct handling of the Python global interpreter lock from managed
 code for code that calls into Python.

-   `PyObject.FromManagedObject` now correctly returns the Python None object
 if the input is a null reference. Also added a new `AsManagedObject`
 method to `PyObject`, making it easier to convert a Python-wrapped managed
 object to the real managed object.

-   Created a simple installer for windows platforms.

1.0.0beta.5

Changed

-   Refactored and fixed threading and global interpreter lock handling,
 which was badly broken before. Also added a number of threading and
 GIL-handling tests.

-   Related to the GIL fixes, added a note to embedders in the README
 about using the AcquireLock and ReleaseLock methods of the PythonEngine
 class to manage the GIL.

-   Fixed a problem in `Single <--> float` conversion for cultures that use
 different decimal symbols than Python.

-   Added a new `ReloadModule` method to the `PythonEngine` class that hooks
 Python module reloading (`PyImport_ReloadModule`).

-   Added a new `StringAsModule` method to the PythonEngine class that can
 create a module from a managed string of code.

-   Added a default `__str__` implementation for Python wrappers of managed
 objects that calls the `ToString` method of the managed object.

1.0.0beta.4

Changed

-   Fixed a problem that made it impossible to override "special" methods
 like `__getitem__` in subclasses of managed classes. Now the tests all
 pass, and there is much rejoicing.

-   Managed classes reflected to Python now have an `__doc__` attribute that
 contains a listing of the class constructor signatures.

-   Fixed a problem that prevented passing null (None) for array arguments.

-   Added a number of new argument conversion tests. Thanks to Laurent
 Caumont for giving Python for .NET a good workout with managed DirectX.

-   Updated the bundled C Python runtime and libraries to Python 2.4. The
 current release is known to also run with Python 2.3. It is known
 _not_ to work with older versions due to changes in CPython type
 object structure.

-   Mostly fixed the differences in the way that import works depending
 on whether you are using the bundled interpreter or an existing Python
 interpreter. The hack I used makes import work uniformly for imports
 done in Python modules. Unfortunately, there is still a limitation
 when using the interpreter interactively: you need to do `import CLR`
 first before importing any sub-names when running with an existing
 Python interpreter.

 The reason is that the first import of `CLR` installs the CLR import
 hook, but for an existing interpreter the standard importer is still
 in control for the duration of that first import, so sub-names won't
 be found until the next import, which will use the now-installed hook.

-   Added support to directly iterate over objects that support IEnumerator
 (as well as IEnumerable). Thanks to Greg Chapman for prodding me ;)

-   Added a section to the README dealing with rebuilding Python for .NET
 against other CPython versions.

-   Fixed a problem with accessing properties when only the interface for
 an object is known. For example, `ICollection(ob).Count` failed because
 Python for .NET mistakenly decided that Count was abstract.

-   Fixed some problems with how COM-based objects are exposed and how
 members of inherited interfaces are exposed. Thanks to Bruce Dodson
 for patches on this.

-   Changed the Runtime class to use a const string to target the
 appropriate CPython dll in DllImport attributes. Now you only
 have to change one line to target a new Python version.

1.0.0beta.3

Changed

-   A dumb bug that could cause a crash on startup on some platforms was
 fixed. Decided to update the beta for this, as a number of people
 were running into the problem.

1.0.0beta.2

Changed

-   Exceptions raised as a result of getting or setting properties were
 not very helpful (target invokation exception). This has been changed
 to pass through the inner exception the way that methods do, which is
 much more likely to be the real exception that caused the problem.

-   Events were refactored as the implementation was based on some bad
 assumptions. As a result, subscription and unsubscription now works
 correctly. A change from beta 1 is that event objects are no longer
 directly callable - this was not appropriate, since the internal
 implementation of an event is private and cant work reliably. Instead,
 you should the appropriate `OnSomeEvent` method published by a class
 to fire an event.

-   The distribution did not include the key file, making it a pain for
 people to build from source. Added the key file to the distribution
 buildout for beta 2.

-   Assemblies can now be found and loaded if they are on the PYTHONPATH.
 Previously only the appbase and the GAC were checked. The system now
 checks PYTHONPATH first, then the appbase, then the GAC.

-   Fixed a bug in constructor invokation during object instantiation.

1.0.0beta.1

Changed

-   Added the baseline of the managed embedding API. Some of the details
 are still subject to change based on some real-world use and feedback.

 The embedding API is based on the `PyObject` class, along with a number
 of specific `PyDict`, `PyList`, (etc.) classes that expose the respective
 interfaces of the built-in Python types. The basic structure and usage
 is intended be familar to anyone who has used Python / C++ wrapper
 libraries like CXX or Boost.

-   Started integrating NUnit2 to support unit tests for the embedding
 layer - still need to add the embedding tests (many already exist,
 but were written for an older version of NUnit).

-   Added Python iteration protocol support for arrays and managed objects
 that implement IEnumerable. This means that you can now use the Python
 idiom `for item in object:` on any array or IEnumerable object.

-   Added automatic conversion from Python sequence types to managed array
 types. This means, for example, that you can now call a managed method
 like AddRange that expects an array with any Python object that supports
 the Python sequence protocol, provided the items of the sequence are
 convertible to the item type of the managed array.

-   Added new demo scripts, mostly more substantial winforms examples.

-   Finished the unit tests for event support, and fixed lots of problems
 with events and delegates as a result. This is one of the trickier
 parts of the integration layer, and there is good coverage of these
 in the unit tests now.

-   Did a fair amount of profiling with an eval version of ANTS (which is
 quite nice, BTW) and made a few changes as a result.

-   Type management was refactored, fixing the issue that caused segfaults
 when GC was enabled. Unit tests, stress tests and demo apps now all run
 nicely with Python GC enabled. There are one or two things left to fix,
 but the fixes should not have any user impact.

-   Changed to base PythonNet on Python 2.3.2. This is considered the most
 stable release, and a good 25 - 30% faster as well.

-   Added a new `CLR.dll` that acts as an extension module that allows an
 existing unmodified Python 2.3 installation to simply `import CLR` to
 bootstrap the managed integration layer.

-   A bug was causing managed methods to only expose overloads declared in
 a particular class, hiding inherited overloads of the same name. Fixed
 the bug and added some unit tests.

-   Added a virtual `__doc__` attribute to managed methods that contains
 the signature of the method. This also means that the Python `help`
 function now provides signature info when used on a managed class.

-   Calling managed methods and events `unbound` (passing the instance as
 the first argument) now works. There is a caveat for methods - if a
 class declares both static and instance methods with the same name,
 it is not possible to call that instance method unbound (the static
 method will always be called).

-   Overload selection for overloaded methods is now much better and uses
 a method resolution algorithm similar to that used by Jython.

-   Changed the managed python.exe wrapper to run as an STA thread, which
 seems to be more compatible with winforms apps. This needs a better
 solution long-term. One possibility would be a command line switch
 so that -sta or -mta could control the python.exe apartment state.

-   Added support for the Python boolean type (True, False). Bool values
 now appear as True or False to Python.

1.0.0alpha.2

Changed

-   Added a Mono makefile. Thanks to Camilo Uribe for help in testing and
 working out problems on Mono. Note that it not currently possible to
 build PythonNet using mono, due to the use of some IL attributes that
 the mono assembler / disassembler doesn't support yet.

-   Preliminary tests show that PythonNet _does_ actually run under mono,
 though the test suite bombs out before the end with an "out of memory"
 error from the mono runtime. It's just a guess at this point, but I
 suspect there may be a limited pool for allocating certain reflection
 structures, and Python uses the reflection infrastructure quite heavily.

-   Removed decoys like the non-working embedding APIs; lots of internal
 refactoring.

-   Implemented indexer support. Managed instances that implement indexers
 can now be used naturally from Python (e.g. `someobject[0]`).

-   Implemented sequence protocol support for managed arrays.

-   Implemented basic thread state management; calls to managed methods
 no longer block Python. I won't go so far as to say the thread
 choreography is "finished", as I don't have a comprehensive set of
 tests to back that up yet (and it will take some work to write a
 sufficiently large and evil set of tests).

-   Fixed a bug that caused conversions of managed strings to PyUnicode to
 produce mangled values in certain situations.

-   Fixed a number of problems related to subclassing a managed class,
 including the fact that it didn't work :)

-   Fixed all of the bugs that were causing tests to fail. This release
 contains all new bugs and new failing tests. Progress! :)

1.0.0alpha.1

Added

-   Initial (mostly) working experimental release.

[keep a changelog]: http://keepachangelog.com/

[semantic versioning]: http://semver.org/

[unreleased]: ../../compare/v2.3.0...HEAD
Links

@pyup-bot pyup-bot added the update label Feb 6, 2023
@Hugovdberg Hugovdberg merged commit 86f2f1f into develop Feb 8, 2023
@Hugovdberg Hugovdberg deleted the pyup/scheduled-update-2023-02-06 branch February 8, 2023 10:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants