Lupa

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

* GH82: Lua coroutines were using the wrong runtime state
(patch by Sergey Dobrov)

* GH81: copy locally provided Lua DLL into installed package on Windows
(patch by Gareth Coles)

* built with Cython 0.25.2

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

* GH70: ``eval()`` and ``execute()`` accept optional positional arguments
(patch by John Vandenberg)

* GH65: calling ``str()`` on a Python object from Lua could fail if the
``LuaRuntime`` is set up without auto-encoding (patch by Mikhail Korobov)

* GH63: attribute/keyword names were not properly encoded if the
``LuaRuntime`` is set up without auto-encoding (patch by Mikhail Korobov)

* built with Cython 0.24

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

* callbacks returned from Lua coroutines were incorrectly mixing
coroutine state with global Lua state (patch by Mikhail Korobov)

* availability of ``python.builtins`` in Lua can be disabled via
``LuaRuntime`` option.

* built with Cython 0.23.4

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

* new module function ``lupa.lua_type()`` that returns the Lua type of
a wrapped object as string, or ``None`` for normal Python objects

* new helper method ``LuaRuntime.table_from(...)`` that creates a Lua
table from one or more Python mappings and/or sequences

* new ``lupa.unpacks_lua_table`` and ``lupa.unpacks_lua_table_method``
decorators to allow calling Python functions from Lua using named
arguments

* fix a hang on shutdown where the LuaRuntime failed to deallocate due
to reference cycles

* Lupa now plays more nicely with other Lua extensions that create
userdata objects

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

* fix a crash when requesting attributes of wrapped Lua coroutine objects

* looking up attributes on Lua objects that do not support it now always
raises an AttributeError instead of sometimes raising a TypeError depending
on the attribute name

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

* NOTE: this release includes the major backwards incompatible changes listed
below. It is believed that they simplify the interaction between Python code
and Lua code by more strongly following idiomatic Lua on the Lua side.

* Instead of passing a wrapped ``python.none`` object into Lua, ``None``
return values are now mapped to ``nil``, making them more straight forward
to handle in Lua code. This makes the behaviour more consistent, as it
was previously somewhat arbitrary where ``none`` could appear and where a
``nil`` value was used. The only remaining exception is during iteration,
where the first returned value must not be ``nil`` in Lua, or otherwise
the loop terminates prematurely. To prevent this, any ``None`` value
that the iterator returns, or any first item in exploded tuples that is
``None``, is still mapped to ``python.none``. Any further values
returned in the same iteration will be mapped to ``nil`` if they are
``None``, not to ``none``. This means that only the first argument
needs to be manually checked for this special case. For the
``enumerate()`` iterator, the counter is never ``None`` and thus the
following unpacked items will never be mapped to ``python.none``.

* When ``unpack_returned_tuples=True``, iteration now also unpacks tuple
values, including ``enumerate()`` iteration, which yields a flat sequence
of counter and unpacked values.

* When calling bound Python methods from Lua as "obj:meth()", Lupa now
prevents Python from prepending the self argument a second time, so that
the Python method is now called as "obj.meth()". Previously, it was called
as "obj.meth(obj)". Note that this can be undesired when the object itself
is explicitly passed as first argument from Lua, e.g. when calling
"func(obj)" where "func" is "obj.meth", but these constellations should be
rare. As a work-around for this case, user code can wrap the bound method
in another function so that the final call comes from Python.

* garbage collection works for reference cycles that span both runtimes,
Python and Lua

* calling from Python into Lua and back into Python did not clean up the
Lua call arguments before the innermost call, so that they could leak
into the nested Python call or its return arguments

* support for Lua 5.2 (in addition to Lua 5.1 and LuaJIT 2.0)

* Lua tables support Python's "del" statement for item deletion
(patch by Jason Fried)

* Attribute lookup can use a more fine-grained control mechanism by
implementing explicit getter and setter functions for a LuaRuntime
(``attribute_handlers`` argument). Patch by Brian Moe.

* item assignments/lookups on Lua objects from Python no longer
special case double underscore names (as opposed to attribute lookups)