[Python-modules-commits] [python-lupa] 01/02: importing python-lupa_1.5+dfsg.orig.tar.gz
Michael Fladischer
fladi at moszumanska.debian.org
Wed Oct 18 09:02:38 UTC 2017
This is an automated email from the git hooks/post-receive script.
fladi pushed a commit to branch debian/master
in repository python-lupa.
commit fba2ed7ee9fe78255db8c036624814e109521599
Author: Michael Fladischer <FladischerMichael at fladi.at>
Date: Wed Oct 18 08:52:19 2017 +0200
importing python-lupa_1.5+dfsg.orig.tar.gz
---
CHANGES.rst | 402 +
INSTALL.rst | 135 +
LICENSE.txt | 19 +
MANIFEST.in | 4 +
PKG-INFO | 1494 ++
README.rst | 927 +
lupa.egg-info/PKG-INFO | 1494 ++
lupa.egg-info/SOURCES.txt | 81 +
lupa.egg-info/dependency_links.txt | 1 +
lupa.egg-info/not-zip-safe | 1 +
lupa.egg-info/top_level.txt | 1 +
lupa/__init__.py | 36 +
lupa/_lupa.c | 34147 +++++++++++++++++++++++++++++++++++
lupa/_lupa.pyx | 1763 ++
lupa/lock.pxi | 118 +
lupa/lua.pxd | 424 +
lupa/lupa_defs.h | 16 +
lupa/tests/__init__.py | 25 +
lupa/tests/test.py | 2609 +++
lupa/version.py | 1 +
setup.cfg | 5 +
setup.py | 359 +
22 files changed, 44062 insertions(+)
diff --git a/CHANGES.rst b/CHANGES.rst
new file mode 100644
index 0000000..3abd1fa
--- /dev/null
+++ b/CHANGES.rst
@@ -0,0 +1,402 @@
+Lupa change log
+===============
+
+1.5 (2017-09-16)
+----------------
+
+* GH#93: New method ``LuaRuntime.compile()`` to compile Lua code
+ without executing it.
+ (patch by TitanSnow)
+
+* GH#91: Lua 5.3 is bundled in the source distribution to simplify
+ one-shot installs.
+ (patch by TitanSnow)
+
+* GH#87: Lua stack trace is included in output in debug mode.
+ (patch by aaiyer)
+
+* GH#78: Allow Lua code to intercept Python exceptions.
+ (patch by Sergey Dobrov)
+
+
+1.4 (2016-12-10)
+----------------
+
+* GH#82: Lua coroutines were using the wrong runtime state
+ (patch by Sergey Dobrov)
+
+* GH#81: copy locally provided Lua DLL into installed package on Windows
+ (patch by Gareth Coles)
+
+* built with Cython 0.25.2
+
+
+1.3 (2016-04-12)
+----------------
+
+* GH#70: ``eval()`` and ``execute()`` accept optional positional arguments
+ (patch by John Vandenberg)
+
+* GH#65: calling ``str()`` on a Python object from Lua could fail if the
+ ``LuaRuntime`` is set up without auto-encoding (patch by Mikhail Korobov)
+
+* GH#63: 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
+
+
+1.2 (2015-10-10)
+----------------
+
+* 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
+
+
+1.1 (2014-11-21)
+----------------
+
+* 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
+
+
+1.0.1 (2014-10-11)
+------------------
+
+* 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
+
+
+1.0 (2014-09-28)
+----------------
+
+* 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)
+
+
+0.21 (2014-02-12)
+-----------------
+
+* some garbage collection issues were cleaned up using new Cython features
+
+* new ``LuaRuntime`` option ``unpack_returned_tuples`` which automatically
+ unpacks tuples returned from Python functions into separate Lua objects
+ (instead of returning a single Python tuple object)
+
+* some internal wrapper classes were removed from the module API
+
+* Windows build fixes
+
+* Py3.x build fixes
+
+* support for building with Lua 5.1 instead of LuaJIT (setup.py --no-luajit)
+
+* no longer uses Cython by default when building from released sources (pass
+ ``--with-cython`` to explicitly request a rebuild)
+
+* requires Cython 0.20+ when building from unreleased sources
+
+* built with Cython 0.20.1
+
+
+0.20 (2011-05-22)
+-----------------
+
+* fix "deallocating None" crash while iterating over Lua tables in
+ Python code
+
+* support for filtering attribute access to Python objects for Lua
+ code
+
+* fix: setting source encoding for Lua code was broken
+
+
+0.19 (2011-03-06)
+-----------------
+
+* fix serious resource leak when creating multiple LuaRuntime instances
+
+* portability fix for binary module importing
+
+
+0.18 (2010-11-06)
+-----------------
+
+* fix iteration by returning ``Py_None`` object for ``None`` instead
+ of ``nil``, which would terminate the iteration
+
+* when converting Python values to Lua, represent ``None`` as a
+ ``Py_None`` object in places where ``nil`` has a special meaning,
+ but leave it as ``nil`` where it doesn't hurt
+
+* support for counter start value in ``python.enumerate()``
+
+* native implementation for ``python.enumerate()`` that is several
+ times faster
+
+* much faster Lua iteration over Python objects
+
+
+0.17 (2010-11-05)
+-----------------
+
+* new helper function ``python.enumerate()`` in Lua that returns a Lua
+ iterator for a Python object and adds the 0-based index to each
+ item.
+
+* new helper function ``python.iterex()`` in Lua that returns a Lua
+ iterator for a Python object and unpacks any tuples that the
+ iterator yields.
+
+* new helper function ``python.iter()`` in Lua that returns a Lua
+ iterator for a Python object.
+
+* reestablished the ``python.as_function()`` helper function for Lua
+ code as it can be needed in cases where Lua cannot determine how to
+ run a Python function.
+
+
+0.16 (2010-09-03)
+-----------------
+
+* dropped ``python.as_function()`` helper function for Lua as all
+ Python objects are callable from Lua now (potentially raising a
+ ``TypeError`` at call time if they are not callable)
+
+* fix regression in 0.13 and later where ordinary Lua functions failed
+ to print due to an accidentally used meta table
+
+* fix crash when calling ``str()`` on wrapped Lua objects without
+ metatable
+
+
+0.15 (2010-09-02)
+-----------------
+
+* support for loading binary Lua modules on systems that support it
+
+
+0.14 (2010-08-31)
+-----------------
+
+* relicensed to the MIT license used by LuaJIT2 to simplify licensing
+ considerations
+
+
+0.13.1 (2010-08-30)
+-------------------
+
+* fix Cython generated C file using Cython 0.13
+
+
+0.13 (2010-08-29)
+-----------------
+
+* fixed undefined behaviour on ``str(lua_object)`` when the object's
+ ``__tostring()`` meta method fails
+
+* removed redundant "error:" prefix from ``LuaError`` messages
+
+* access to Python's ``python.builtins`` from Lua code
+
+* more generic wrapping rules for Python objects based on supported
+ protocols (callable, getitem, getattr)
+
+* new helper functions ``as_attrgetter()`` and ``as_itemgetter()`` to
+ specify the Python object protocol used by Lua indexing when
+ wrapping Python objects in Python code
+
+* new helper functions ``python.as_attrgetter()``,
+ ``python.as_itemgetter()`` and ``python.as_function()`` to specify
+ the Python object protocol used by Lua indexing of Python objects in
+ Lua code
+
+* item and attribute access for Python objects from Lua code
+
+
+0.12 (2010-08-16)
+-----------------
+
+* fix Lua stack leak during table iteration
+
+* fix lost Lua object reference after iteration
+
+
+0.11 (2010-08-07)
+-----------------
+
+* error reporting on Lua syntax errors failed to clean up the stack so
+ that errors could leak into the next Lua run
+
+* Lua error messages were not properly decoded
+
+
+0.10 (2010-07-27)
+-----------------
+
+* much faster locking of the LuaRuntime, especially in the single
+ threaded case (see
+ http://code.activestate.com/recipes/577336-fast-re-entrant-optimistic-lock-implemented-in-cyt/)
+
+* fixed several error handling problems when executing Python code
+ inside of Lua
+
+
+0.9 (2010-07-23)
+----------------
+
+* fixed Python special double-underscore method access on LuaObject
+ instances
+
+* Lua coroutine support through dedicated wrapper classes, including
+ Python iteration support. In Python space, Lua coroutines behave
+ exactly like Python generators.
+
+
+0.8 (2010-07-21)
+----------------
+
+* support for returning multiple values from Lua evaluation
+
+* ``repr()`` support for Lua objects
+
+* ``LuaRuntime.table()`` method for creating Lua tables from Python
+ space
+
+* encoding fix for ``str(LuaObject)``
+
+
+0.7 (2010-07-18)
+----------------
+
+* ``LuaRuntime.require()`` and ``LuaRuntime.globals()`` methods
+
+* renamed ``LuaRuntime.run()`` to ``LuaRuntime.execute()``
+
+* support for ``len()``, ``setattr()`` and subscripting of Lua objects
+
+* provide all built-in Lua libraries in ``LuaRuntime``, including
+ support for library loading
+
+* fixed a thread locking issue
+
+* fix passing Lua objects back into the runtime from Python space
+
+
+0.6 (2010-07-18)
+----------------
+
+* Python iteration support for Lua objects (e.g. tables)
+
+* threading fixes
+
+* fix compile warnings
+
+
+0.5 (2010-07-14)
+----------------
+
+* explicit encoding options per LuaRuntime instance to decode/encode
+ strings and Lua code
+
+
+0.4 (2010-07-14)
+----------------
+
+* attribute read access on Lua objects, e.g. to read Lua table values
+ from Python
+
+* str() on Lua objects
+
+* include .hg repository in source downloads
+
+* added missing files to source distribution
+
+
+0.3 (2010-07-13)
+----------------
+
+* fix several threading issues
+
+* safely free the GIL when calling into Lua
+
+
+0.2 (2010-07-13)
+----------------
+
+* propagate Python exceptions through Lua calls
+
+
+0.1 (2010-07-12)
+----------------
+
+* first public release
diff --git a/INSTALL.rst b/INSTALL.rst
new file mode 100644
index 0000000..302a794
--- /dev/null
+++ b/INSTALL.rst
@@ -0,0 +1,135 @@
+Installing lupa
+===============
+
+Building with LuaJIT2
+---------------------
+
+#) Download and unpack lupa
+
+ http://pypi.python.org/pypi/lupa
+
+#) Download LuaJIT2
+
+ http://luajit.org/download.html
+
+#) Unpack the archive into the lupa base directory, e.g.::
+
+ .../lupa-0.1/LuaJIT-2.0.2
+
+#) Build LuaJIT::
+
+ cd LuaJIT-2.0.2
+ make
+ cd ..
+
+ If you need specific C compiler flags, pass them to ``make`` as follows::
+
+ make CFLAGS="..."
+
+ For trickier target platforms like Windows and MacOS-X, please see
+ the official `installation instructions for LuaJIT`_.
+
+ NOTE: When building on Windows, make sure that lua51.lib is made in addition
+ to lua51.dll. The MSVC build produces this file, MinGW does NOT.
+
+#) Build lupa::
+
+ python setup.py install
+
+ Or any other distutils target of your choice, such as ``build``
+ or one of the ``bdist`` targets. See the `distutils
+ documentation`_ for help, also the `hints on building extension
+ modules`_.
+
+ Note that on 64bit MacOS-X installations, the following additional
+ compiler flags are reportedly required due to the embedded LuaJIT::
+
+ -pagezero_size 10000 -image_base 100000000
+
+ You can find additional installation hints for MacOS-X in this
+ `somewhat unclear blog post`_, which may or may not tell you at
+ which point in the installation process to provide these flags.
+
+ Also, on 64bit MacOS-X, you will typically have to set the
+ environment variable ``ARCHFLAGS`` to make sure it only builds
+ for your system instead of trying to generate a fat binary with
+ both 32bit and 64bit support::
+
+ export ARCHFLAGS="-arch x86_64"
+
+ Note that this applies to both LuaJIT and Lupa, so make sure
+ you try a clean build of everything if you forgot to set it
+ initially.
+
+.. _`installation instructions for LuaJIT`: http://luajit.org/install.html
+.. _`somewhat unclear blog post`: http://t-p-j.blogspot.com/2010/11/lupa-on-os-x-with-macports-python-26.html
+.. _`distutils documentation`: http://docs.python.org/install/index.html#install-index
+.. _`hints on building extension modules`: http://docs.python.org/install/index.html#building-extensions-tips-and-tricks
+
+
+Building with Lua 5.1
+---------------------
+
+Reportedly, it also works to use Lupa with the standard (non-JIT) Lua
+runtime. To that end, install Lua 5.1 instead of LuaJIT2, including
+any development packages (header files etc.).
+
+On systems that use the "pkg-config" configuration mechanism, Lupa's
+setup.py will pick up either LuaJIT2 or Lua automatically, with a
+preference for LuaJIT2 if it is found. Pass the ``--no-luajit`` option
+to the setup.py script if you have both installed but do not want to
+use LuaJIT2.
+
+On other systems, you may have to supply the build parameters
+externally, e.g. using environment variables or by changing the
+setup.py script manually. Pass the ``--no-luajit`` option to the
+setup.py script in order to ignore the failure you get when neither
+LuaJIT2 nor Lua are found automatically.
+
+For further information, read this mailing list post:
+
+http://article.gmane.org/gmane.comp.python.lupa.devel/31
+
+
+Installing lupa from packages
+=============================
+
+Debian/Ubuntu + Lua 5.2
+-----------------------
+
+#) Install Lua 5.2 development package::
+
+ $ apt-get install liblua5.2-dev
+
+#) Install lupa::
+
+ $ pip install lupa
+
+Debian/Ubuntu + LuaJIT2
+-----------------------
+
+#) Install LuaJIT2 development package::
+
+ $ apt-get install libluajit-5.1-dev
+
+#) Install lupa::
+
+ $ pip install lupa
+
+Depending on OS version, you might get an older LuaJIT2 version.
+
+OS X + Lua 5.2 + Homebrew
+-------------------------
+
+#) Install Lua::
+
+ $ brew install lua
+
+#) Install pkg-config::
+
+ $ brew install pkg-config
+
+#) Install lupa::
+
+ $ pip install lupa
+
diff --git a/LICENSE.txt b/LICENSE.txt
new file mode 100644
index 0000000..de1967d
--- /dev/null
+++ b/LICENSE.txt
@@ -0,0 +1,19 @@
+Copyright (c) 2010 Stefan Behnel. All rights reserved.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.
diff --git a/MANIFEST.in b/MANIFEST.in
new file mode 100644
index 0000000..a8787ba
--- /dev/null
+++ b/MANIFEST.in
@@ -0,0 +1,4 @@
+include MANIFEST.in
+include CHANGES.rst INSTALL.rst LICENSE.txt README.rst
+recursive-include lupa *.py *.pyx *.pxd *.pxi *.c *.h
+recursive-include third-party *.c *.h
diff --git a/PKG-INFO b/PKG-INFO
new file mode 100644
index 0000000..46be1dc
--- /dev/null
+++ b/PKG-INFO
@@ -0,0 +1,1494 @@
+Metadata-Version: 1.1
+Name: lupa
+Version: 1.5
+Summary: Python wrapper around Lua and LuaJIT
+Home-page: https://github.com/scoder/lupa
+Author: Lupa-dev mailing list
+Author-email: lupa-dev at freelists.org
+License: MIT style
+Description: Lupa
+ ====
+
+ Lupa integrates the runtimes of Lua_ or LuaJIT2_ into CPython.
+ It is a partial rewrite of LunaticPython_ in Cython_ with some
+ additional features such as proper coroutine support.
+
+ .. _Lua: http://lua.org/
+ .. _LuaJIT2: http://luajit.org/
+ .. _LunaticPython: http://labix.org/lunatic-python
+ .. _Cython: http://cython.org
+
+ For questions not answered here, please contact the `Lupa mailing list`_.
+
+ .. _`Lupa mailing list`: http://www.freelists.org/list/lupa-dev
+
+ .. contents:: :local:
+
+
+ Major features
+ --------------
+
+ * separate Lua runtime states through a ``LuaRuntime`` class
+
+ * Python coroutine wrapper for Lua coroutines
+
+ * iteration support for Python objects in Lua and Lua objects in
+ Python
+
+ * proper encoding and decoding of strings (configurable per runtime,
+ UTF-8 by default)
+
+ * frees the GIL and supports threading in separate runtimes when
+ calling into Lua
+
+ * tested with Python 2.6/3.2 and later
+
+ * written for LuaJIT2 (tested with LuaJIT 2.0.2), but also works
+ with the normal Lua interpreter (5.1 and 5.2)
+
+ * easy to hack on and extend as it is written in Cython, not C
+
+
+ Why the name?
+ -------------
+
+ In Latin, "lupa" is a female wolf, as elegant and wild as it sounds.
+ If you don't like this kind of straight forward allegory to an
+ endangered species, you may also happily assume it's just an
+ amalgamation of the phonetic sounds that start the words "Lua" and
+ "Python", two from each to keep the balance.
+
+
+ Why use it?
+ -----------
+
+ It complements Python very well. Lua is a language as dynamic as
+ Python, but LuaJIT compiles it to very fast machine code, sometimes
+ faster than many statically compiled languages for computational code.
+ The language runtime is very small and carefully designed for
+ embedding. The complete binary module of Lupa, including a statically
+ linked LuaJIT2 runtime, only weighs some 700KB on a 64 bit machine.
+ With standard Lua 5.1, it's less than 400KB.
+
+ However, the Lua ecosystem lacks many of the batteries that Python
+ readily includes, either directly in its standard library or as third
+ party packages. This makes real-world Lua applications harder to write
+ than equivalent Python applications. Lua is therefore not commonly
+ used as primary language for large applications, but it makes for a
+ fast, high-level and resource-friendly backup language inside of
+ Python when raw speed is required and the edit-compile-run cycle of
+ binary extension modules is too heavy and too static for agile
+ development or hot-deployment.
+
+ Lupa is a very fast and thin wrapper around Lua or LuaJIT. It makes it
+ easy to write dynamic Lua code that accompanies dynamic Python code by
+ switching between the two languages at runtime, based on the tradeoff
+ between simplicity and speed.
+
+
+ Examples
+ --------
+
+ ..
+ ## doctest helpers:
+ >>> try: _ = sorted
+ ... except NameError:
+ ... def sorted(seq):
+ ... l = list(seq)
+ ... l.sort()
+ ... return l
+
+ .. code:: python
+
+ >>> import lupa
+ >>> from lupa import LuaRuntime
+ >>> lua = LuaRuntime(unpack_returned_tuples=True)
+
+ >>> lua.eval('1+1')
+ 2
+
+ >>> lua_func = lua.eval('function(f, n) return f(n) end')
+
+ >>> def py_add1(n): return n+1
+ >>> lua_func(py_add1, 2)
+ 3
+
+ >>> lua.eval('python.eval(" 2 ** 2 ")') == 4
+ True
+ >>> lua.eval('python.builtins.str(4)') == '4'
+ True
+
+ The function ``lua_type(obj)`` can be used to find out the type of a
+ wrapped Lua object in Python code, as provided by Lua's ``type()``
+ function:
+
+ .. code:: python
+
+ >>> lupa.lua_type(lua_func)
+ 'function'
+ >>> lupa.lua_type(lua.eval('{}'))
+ 'table'
+
+ To help in distinguishing between wrapped Lua objects and normal
+ Python objects, it returns ``None`` for the latter:
+
+ .. code:: python
+
+ >>> lupa.lua_type(123) is None
+ True
+ >>> lupa.lua_type('abc') is None
+ True
+ >>> lupa.lua_type({}) is None
+ True
+
+ Note the flag ``unpack_returned_tuples=True`` that is passed to create
+ the Lua runtime. It is new in Lupa 0.21 and changes the behaviour of
+ tuples that get returned by Python functions. With this flag, they
+ explode into separate Lua values:
+
+ .. code:: python
+
+ >>> lua.execute('a,b,c = python.eval("(1,2)")')
+ >>> g = lua.globals()
+ >>> g.a
+ 1
+ >>> g.b
+ 2
+ >>> g.c is None
+ True
+
+ When set to False, functions that return a tuple pass it through to the
+ Lua code:
+
+ .. code:: python
+
+ >>> non_explode_lua = lupa.LuaRuntime(unpack_returned_tuples=False)
+ >>> non_explode_lua.execute('a,b,c = python.eval("(1,2)")')
+ >>> g = non_explode_lua.globals()
+ >>> g.a
+ (1, 2)
+ >>> g.b is None
+ True
+ >>> g.c is None
+ True
+
+ Since the default behaviour (to not explode tuples) might change in a
+ later version of Lupa, it is best to always pass this flag explicitly.
+
+
+ Python objects in Lua
+ ---------------------
+
+ Python objects are either converted when passed into Lua (e.g.
+ numbers and strings) or passed as wrapped object references.
+
+ .. code:: python
+
+ >>> wrapped_type = lua.globals().type # Lua's own type() function
+ >>> wrapped_type(1) == 'number'
+ True
+ >>> wrapped_type('abc') == 'string'
+ True
+
+ Wrapped Lua objects get unwrapped when they are passed back into Lua,
+ and arbitrary Python objects get wrapped in different ways:
+
+ .. code:: python
+
+ >>> wrapped_type(wrapped_type) == 'function' # unwrapped Lua function
+ True
+ >>> wrapped_type(len) == 'userdata' # wrapped Python function
+ True
+ >>> wrapped_type([]) == 'userdata' # wrapped Python object
+ True
+
+ Lua supports two main protocols on objects: calling and indexing. It
+ does not distinguish between attribute access and item access like
+ Python does, so the Lua operations ``obj[x]`` and ``obj.x`` both map
+ to indexing. To decide which Python protocol to use for Lua wrapped
+ objects, Lupa employs a simple heuristic.
+
+ Pratically all Python objects allow attribute access, so if the object
+ also has a ``__getitem__`` method, it is preferred when turning it
+ into an indexable Lua object. Otherwise, it becomes a simple object
+ that uses attribute access for indexing from inside Lua.
+
+ Obviously, this heuristic will fail to provide the required behaviour
+ in many cases, e.g. when attribute access is required to an object
+ that happens to support item access. To be explicit about the
+ protocol that should be used, Lupa provides the helper functions
+ ``as_attrgetter()`` and ``as_itemgetter()`` that restrict the view on
+ an object to a certain protocol, both from Python and from inside
+ Lua:
+
+ .. code:: python
+
+ >>> lua_func = lua.eval('function(obj) return obj["get"] end')
+ >>> d = {'get' : 'value'}
+
+ >>> value = lua_func(d)
+ >>> value == d['get'] == 'value'
+ True
+
+ >>> value = lua_func( lupa.as_itemgetter(d) )
+ >>> value == d['get'] == 'value'
+ True
+
+ >>> dict_get = lua_func( lupa.as_attrgetter(d) )
+ >>> dict_get == d.get
+ True
+ >>> dict_get('get') == d.get('get') == 'value'
+ True
+
+ >>> lua_func = lua.eval(
+ ... 'function(obj) return python.as_attrgetter(obj)["get"] end')
+ >>> dict_get = lua_func(d)
+ >>> dict_get('get') == d.get('get') == 'value'
+ True
+
+ Note that unlike Lua function objects, callable Python objects support
+ indexing in Lua:
+
+ .. code:: python
+
+ >>> def py_func(): pass
+ >>> py_func.ATTR = 2
+
+ >>> lua_func = lua.eval('function(obj) return obj.ATTR end')
+ >>> lua_func(py_func)
+ 2
+ >>> lua_func = lua.eval(
+ ... 'function(obj) return python.as_attrgetter(obj).ATTR end')
+ >>> lua_func(py_func)
+ 2
+ >>> lua_func = lua.eval(
+ ... 'function(obj) return python.as_attrgetter(obj)["ATTR"] end')
+ >>> lua_func(py_func)
+ 2
+
+
+ Iteration in Lua
+ ----------------
+
+ Iteration over Python objects from Lua's for-loop is fully supported.
+ However, Python iterables need to be converted using one of the
+ utility functions which are described here. This is similar to the
+ functions like ``pairs()`` in Lua.
+
+ To iterate over a plain Python iterable, use the ``python.iter()``
+ function. For example, you can manually copy a Python list into a Lua
+ table like this:
+
+ .. code:: python
+
+ >>> lua_copy = lua.eval('''
+ ... function(L)
+ ... local t, i = {}, 1
+ ... for item in python.iter(L) do
+ ... t[i] = item
+ ... i = i + 1
+ ... end
+ ... return t
+ ... end
+ ... ''')
+
+ >>> table = lua_copy([1,2,3,4])
+ >>> len(table)
+ 4
+ >>> table[1] # Lua indexing
+ 1
+
+ Python's ``enumerate()`` function is also supported, so the above
+ could be simplified to:
+
+ .. code:: python
+
+ >>> lua_copy = lua.eval('''
+ ... function(L)
+ ... local t = {}
+ ... for index, item in python.enumerate(L) do
+ ... t[ index+1 ] = item
+ ... end
+ ... return t
+ ... end
+ ... ''')
+
+ >>> table = lua_copy([1,2,3,4])
+ >>> len(table)
+ 4
+ >>> table[1] # Lua indexing
+ 1
+
+ For iterators that return tuples, such as ``dict.iteritems()``, it is
+ convenient to use the special ``python.iterex()`` function that
+ automatically explodes the tuple items into separate Lua arguments:
+
+ .. code:: python
+
+ >>> lua_copy = lua.eval('''
+ ... function(d)
+ ... local t = {}
+ ... for key, value in python.iterex(d.items()) do
+ ... t[key] = value
+ ... end
+ ... return t
+ ... end
+ ... ''')
+
+ >>> d = dict(a=1, b=2, c=3)
+ >>> table = lua_copy( lupa.as_attrgetter(d) )
+ >>> table['b']
+ 2
+
+ Note that accessing the ``d.items`` method from Lua requires passing
+ the dict as ``attrgetter``. Otherwise, attribute access in Lua would
+ use the ``getitem`` protocol of Python dicts and look up ``d['items']``
+ instead.
+
+
+ None vs. nil
+ ------------
+
+ While ``None`` in Python and ``nil`` in Lua differ in their semantics, they
+ usually just mean the same thing: no value. Lupa therefore tries to map one
+ directly to the other whenever possible:
+
+ .. code:: python
+
+ >>> lua.eval('nil') is None
+ True
+ >>> is_nil = lua.eval('function(x) return x == nil end')
+ >>> is_nil(None)
+ True
+
+ The only place where this cannot work is during iteration, because Lua
+ considers a ``nil`` value the termination marker of iterators. Therefore,
+ Lupa special cases ``None`` values here and replaces them by a constant
+ ``python.none`` instead of returning ``nil``:
+
+ .. code:: python
+
+ >>> _ = lua.require("table")
+ >>> func = lua.eval('''
+ ... function(items)
+ ... local t = {}
+ ... for value in python.iter(items) do
+ ... table.insert(t, value == python.none)
+ ... end
+ ... return t
+ ... end
+ ... ''')
... 43225 lines suppressed ...
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/python-modules/packages/python-lupa.git
More information about the Python-modules-commits
mailing list