redis-lua-py 0.5.1__tar.gz → 0.7.0__tar.gz

redis_lua_py-0.7.0/.release-please-manifest.json

@@ -0,0 +1,3 @@
+{
+  ".": "0.7.0"
+}

{redis_lua_py-0.5.1 → redis_lua_py-0.7.0}/CHANGELOG.md

@@ -7,6 +7,30 @@ are written by [release-please](https://github.com/googleapis/release-please)
 from the conventional commit subjects on `main`; see
 [CONTRIBUTING.md](CONTRIBUTING.md) for how a release is cut.
 
+## [0.7.0](https://github.com/IgnaceMaes/redis-lua-py/compare/v0.6.0...v0.7.0) (2026-09-12)
+
+
+### ⚠ BREAKING CHANGES
+
+* a + b where neither side is known to be a number or a string now joins two strings instead of adding them as numbers, as Python does, so wrap a side in int to add. Integer keys of a dict the compiler knows to be one are no longer shifted by one, and a lambda or helper function that reads a loop variable is refused.
+
+### Added
+
+* compile lambdas, chained comparisons and slice steps, and tell dicts from lists ([6024009](https://github.com/IgnaceMaes/redis-lua-py/commit/6024009eaefeb20ccb743225c609799aa332f7c2))
+* support coredis clients ([#22](https://github.com/IgnaceMaes/redis-lua-py/issues/22)) ([3d07a89](https://github.com/IgnaceMaes/redis-lua-py/commit/3d07a89f5b4c55eddca3a1f3bae5f45b41fd4156))
+
+
+### Changed
+
+* split the compiler into a package of modules ([#20](https://github.com/IgnaceMaes/redis-lua-py/issues/20)) ([5f67766](https://github.com/IgnaceMaes/redis-lua-py/commit/5f67766f015c038086894f3b61fa76d6f9deef12))
+
+## [0.6.0](https://github.com/IgnaceMaes/redis-lua-py/compare/v0.5.1...v0.6.0) (2026-09-12)
+
+
+### Added
+
+* generate typed functions that call scripts the way `@script` does ([#18](https://github.com/IgnaceMaes/redis-lua-py/issues/18)) ([8f602f7](https://github.com/IgnaceMaes/redis-lua-py/commit/8f602f7bdf4afaa22c83c63e215ef5d965fbc584))
+
 ## [0.5.1](https://github.com/IgnaceMaes/redis-lua-py/compare/v0.5.0...v0.5.1) (2026-09-12)
 
 

{redis_lua_py-0.5.1 → redis_lua_py-0.7.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: redis-lua-py
-Version: 0.5.1
+Version: 0.7.0
 Summary: Write Redis Lua scripts as real Python functions, not strings.
 Project-URL: Homepage, https://ignacemaes.com/redis-lua-py/
 Project-URL: Documentation, https://ignacemaes.com/redis-lua-py/
@@ -40,7 +40,7 @@ Description-Content-Type: text/markdown
 
 <p align="center">
   Write Redis Lua scripts as real Python functions, not as strings.<br>
-  Compiled at import, checked by <code>mypy</code>, sent with <code>EVALSHA</code>. Sync and async redis-py.
+  Compiled at import, checked by <code>mypy</code>, sent with <code>EVALSHA</code>. Sync and async redis-py, and coredis.
 </p>
 
 <p align="center">
@@ -141,12 +141,13 @@ script cache is cold once per script rather than once per environment.
   a script is a `CompiledScript[R]`, and an async client gives you
   `Awaitable[R]`.
 - **[Sync and async](https://ignacemaes.com/redis-lua-py/guide/async/)** from
-  the same script object, and
+  the same script object, with redis-py or coredis, and
   **[`bind`](https://ignacemaes.com/redis-lua-py/guide/binding-a-client/)** when
   passing the client every time gets repetitive.
 - **[Build-time generation](https://ignacemaes.com/redis-lua-py/guide/build-time/)**
-  for libraries — `python -m redis_lua_py generate` writes the Lua to a module
-  of plain strings, so your users never depend on this package, and `--check`
+  for libraries — `python -m redis_lua_py generate` writes your scripts to a
+  module of typed functions that needs only the standard library, called just
+  like the `@script`, so your users never depend on this package. `--check`
   keeps it current in CI.
 - **[Redis Functions](https://ignacemaes.com/redis-lua-py/guide/redis-functions/)** —
   the same Python compiles into a function library, loaded with `FUNCTION LOAD`

{redis_lua_py-0.5.1 → redis_lua_py-0.7.0}/README.md

@@ -14,7 +14,7 @@
 
 <p align="center">
   Write Redis Lua scripts as real Python functions, not as strings.<br>
-  Compiled at import, checked by <code>mypy</code>, sent with <code>EVALSHA</code>. Sync and async redis-py.
+  Compiled at import, checked by <code>mypy</code>, sent with <code>EVALSHA</code>. Sync and async redis-py, and coredis.
 </p>
 
 <p align="center">
@@ -115,12 +115,13 @@ script cache is cold once per script rather than once per environment.
   a script is a `CompiledScript[R]`, and an async client gives you
   `Awaitable[R]`.
 - **[Sync and async](https://ignacemaes.com/redis-lua-py/guide/async/)** from
-  the same script object, and
+  the same script object, with redis-py or coredis, and
   **[`bind`](https://ignacemaes.com/redis-lua-py/guide/binding-a-client/)** when
   passing the client every time gets repetitive.
 - **[Build-time generation](https://ignacemaes.com/redis-lua-py/guide/build-time/)**
-  for libraries — `python -m redis_lua_py generate` writes the Lua to a module
-  of plain strings, so your users never depend on this package, and `--check`
+  for libraries — `python -m redis_lua_py generate` writes your scripts to a
+  module of typed functions that needs only the standard library, called just
+  like the `@script`, so your users never depend on this package. `--check`
   keeps it current in CI.
 - **[Redis Functions](https://ignacemaes.com/redis-lua-py/guide/redis-functions/)** —
   the same Python compiles into a function library, loaded with `FUNCTION LOAD`

{redis_lua_py-0.5.1 → redis_lua_py-0.7.0}/docs/guide/async.md

@@ -27,3 +27,31 @@ own script machinery, which this defers to rather than reimplementing.
 
 [`bind`](binding-a-client.md) works on async clients just as well, and carries
 the awaitable through.
+
+## coredis
+
+[coredis](https://github.com/alisaifee/coredis), which is async only, works
+the same way. A script, a bound script and a
+[library function](redis-functions.md) each return an awaitable, and the
+overloads type it as `Awaitable[R]`:
+
+```python
+import coredis
+
+async with coredis.Redis() as client:
+    remaining = await rate_limit(client, key="user:42", limit=10, ttl=60)
+```
+
+Script caching is coredis's own `register_script`, which reloads a script the
+server has dropped. In a coredis pipeline a call is queued like any other
+command, and coredis loads the pipeline's scripts before running it; await
+each call once the `async with` block has run the pipeline:
+
+```python
+async with client.pipeline() as pipe:
+    queued = rate_limit(pipe, key="user:42", limit=10, ttl=60)
+remaining = await queued
+```
+
+As with redis-py, a client created with `decode_responses=True` decodes
+replies, so a script annotated `bytes` returns `str` from it.

redis_lua_py-0.7.0/docs/guide/build-time.md

@@ -0,0 +1,196 @@
+# Shipping without the dependency
+
+Calling a script needs redis-lua-py at runtime: it compiles the body when the
+module is imported, and resolves keys and arguments on every call. In an
+application that is a dependency you chose. In a library it is a dependency
+every one of your users inherits, along with the import-time compile, for Lua
+that never changes between your releases.
+
+So a library can compile ahead of time instead. You write the scripts with
+`@script`, as anywhere else, and generate a module from them while you
+develop. What you ship is that module: plain Python that needs only the
+standard library, with a typed function per script, called exactly the way
+the `@script` would be.
+
+## Generate a module
+
+Keep the scripts outside the package you ship, and redis-lua-py in your
+development dependencies:
+
+```bash
+uv add --dev redis-lua-py
+```
+
+```
+myproj/
+├── pyproject.toml
+├── redis_scripts/
+│   └── limits.py      # the @script functions; never shipped
+└── src/myproj/
+    ├── _lua.py        # generated, checked in, shipped
+    └── limits.py      # the code that runs them
+```
+
+Then, from the project root:
+
+```bash
+python -m redis_lua_py generate redis_scripts.limits --out src/myproj/_lua.py
+```
+
+Your library calls the generated functions the way it would call the scripts
+themselves:
+
+```python
+from redis import Redis
+
+from ._lua import rate_limit
+
+
+def hit(client: Redis, key: str, limit: int, ttl: int) -> int:
+    return rate_limit(client, key=key, limit=limit, ttl=ttl)
+```
+
+Moving from `@script` to generated code, or back, is a change of import. A sync
+client gets a value and an async one an awaitable, `EVALSHA` falls back to
+`EVAL` when the server has dropped the script, and a cluster pipeline is sent
+the source: the generated module carries a copy of the code the package itself
+calls scripts with.
+
+## What the module holds
+
+For each script, its Lua as a constant named after it in capitals, and a
+function with the signature it was written with:
+
+```python
+# rate_limit -- KEYS: key; ARGV: limit, ttl
+RATE_LIMIT = """\
+-- rate_limit
+-- Generated by redis-lua-py from redis_scripts/limits.py:6. Do not edit.
+local key = KEYS[1]
+local limit = tonumber(ARGV[1])
+local ttl = tonumber(ARGV[2])
+local current = redis.call('INCR', key)
+if current == 1 then
+  redis.call('EXPIRE', key, ttl)
+end
+if current > limit then
+  return -1
+end
+return limit - current
+"""
+_RATE_LIMIT_CLIENTS: WeakKeyDictionary[Any, Any] = WeakKeyDictionary()
+
+
+@overload
+def rate_limit(
+    client: _AsyncClient,
+    /,
+    key: _Key,
+    limit: int,
+    ttl: int,
+) -> Awaitable[int]: ...
+@overload
+def rate_limit(client: Any, /, key: _Key, limit: int, ttl: int) -> int: ...
+def rate_limit(client: Any, /, key: _Key, limit: int, ttl: int) -> Any:
+    return _run(
+        RATE_LIMIT,
+        _RATE_LIMIT_CLIENTS,
+        client,
+        [key],
+        [_encode("limit", limit), _encode("ttl", ttl)],
+    )
+```
+
+Because it is a real signature, Python itself refuses a missing, misspelled or
+duplicated argument, and your type checker sees every call, including what it
+returns from a sync client and from an async one. Parameter names, their
+order, keyword-only parameters and the docstring all come from the script.
+
+The types come from the script's annotations, as far as a module that imports
+nothing of yours can repeat them:
+
+| Parameter | Accepts |
+| --- | --- |
+| annotated `Key` | `str \| bytes \| memoryview`, as redis-py does for a key |
+| `list[Key]`, or `list[...]` of arguments | any iterable of those, as `@script` does |
+| an argument annotated with builtins only, such as `int` or `str \| bytes` | exactly that |
+| an argument annotated with anything else | `str \| bytes \| memoryview \| int \| float` |
+
+A return annotation made only of builtins, such as `list[bytes] | None`, is kept
+as written; anything else becomes `Any`. A value Redis has no representation
+for, such as `None`, raises `TypeError`, as does a string passed where a list
+belongs.
+
+Above the scripts sits that copied call path, about a hundred lines, every name
+in it private. A script or parameter named like one of them would shadow it, so
+generation refuses one and names it.
+
+Every path in the file is relative to the project root, so it comes out
+byte-for-byte the same on every machine, and regenerating it without a change
+to the scripts leaves it untouched. It is laid out the way black and ruff
+format code, and passes strict mypy.
+
+If you would rather call redis-py yourself, the constants are there for that:
+`client.register_script(RATE_LIMIT)`, with `keys` and `args` in the order the
+comment above each one records.
+
+## Or one `.lua` file per script
+
+Pass a directory instead of a `.py` path:
+
+```bash
+python -m redis_lua_py generate redis_scripts.limits --out src/myproj/lua/
+```
+
+That writes `rate_limit.lua` and a file for every other script, for a library
+that already loads its Lua from files. When a script is renamed or removed, its
+old file is deleted. Only files carrying the generated header are ever
+deleted, so hand-written Lua in the same directory is safe. The flip side is
+that a script compiled with `header=False` leaves its old file behind when it
+is renamed.
+
+## Keep it current
+
+Checking generated code in only works if something notices when it goes stale.
+`--check` writes nothing, and exits 1 with a diff if the output no longer
+matches the scripts. Run it in CI:
+
+```yaml
+- run: uv run python -m redis_lua_py generate redis_scripts.limits --out src/myproj/_lua.py --check
+```
+
+Or as a test, which fails with the same diff:
+
+```python
+from redis_lua_py import codegen
+
+
+def test_generated_lua_is_current():
+    codegen.check("redis_scripts.limits", "src/myproj/_lua.py")
+```
+
+A test imports `redis_scripts.limits` like any other module, so the project
+root has to be on the path. With pytest, set `pythonpath = ["."]` under
+`[tool.pytest.ini_options]`.
+
+## What you give up
+
+The generated Lua is identical to what a `@script` call would send, and the
+call path is the same code. What differs is at the edges:
+
+- **Errors.** A bad argument raises `TypeError`, not
+  [`ScriptArgumentError`](../reference/errors.md#scriptargumenterror), which
+  lives in this package.
+- **`bind`.** A generated function takes the client on every call. Wrap it in a
+  function of your own if that gets repetitive.
+- **Your own types.** An annotation that names a type from your module is
+  widened, as in the table above.
+- **Redis Functions.** Only `@script` functions are generated, not a
+  [`Library`](redis-functions.md).
+
+Keep testing the scripts against
+[fakeredis](testing.md#run-the-behaviour-without-a-server), through the
+generated module or through `@script`: both run the same Lua.
+
+The script module itself is ordinary Python, so point your type checker and
+linter at it along with the rest of the project.

{redis_lua_py-0.5.1 → redis_lua_py-0.7.0}/docs/guide/redis-functions.md

@@ -34,7 +34,8 @@ peek(client, key="user:42")  # FCALL_RO peek 1 user:42
 
 A function is called like a script: pass a sync client and you get a value,
 an async one and you get an awaitable, and [`bind`](binding-a-client.md)
-works the same way.
+works the same way. With a [coredis](async.md#coredis) client, the call goes
+through its `fcall` or `fcall_ro`, and loading through its `function_load`.
 
 ## Loading
 
@@ -51,10 +52,11 @@ limits.load(client)
 
     A call queued in a pipeline cannot load the library halfway through
     `execute()`. Call `load()` before queueing calls to a library the server
-    may not have yet.
+    may not have yet. The same goes for a coredis pipeline, which runs when its
+    `async with` block ends: `await limits.load(client)` before entering it.
 
-On Redis Cluster, redis-py sends `FUNCTION LOAD` to every primary, and routes
-`FCALL` on the function's keys, as it does a script.
+On Redis Cluster, redis-py and coredis send `FUNCTION LOAD` to every primary,
+and route `FCALL` on the function's keys, as they do a script.
 
 ## What the library looks like
 

{redis_lua_py-0.5.1 → redis_lua_py-0.7.0}/docs/index.md

@@ -6,7 +6,7 @@ hide:
 # redis-lua-py
 
 Write Redis Lua scripts as real Python functions, not as strings. Compiled at
-import, checked by `mypy`, sent with `EVALSHA`. Sync and async redis-py.
+import, checked by `mypy`, sent with `EVALSHA`. Sync and async redis-py, and coredis.
 
 ```python
 from redis_lua_py import Key, redis, script
@@ -68,7 +68,8 @@ requirements, or go straight to the [Quickstart](quickstart.md).
 - **Typed on the caller's side.** A script is a `CompiledScript[R]`, so
   `rate_limit(...)` returns an `int` rather than `Any`, and an async client
   gives you `Awaitable[R]`. See [What the caller gets](guide/return-values.md).
-- **Sync and async from the same script object.** See [Async](guide/async.md).
+- **Sync and async from the same script object**, with redis-py or coredis.
+  See [Async](guide/async.md).
 - **Binary-safe throughout.** Nothing here decodes. See
   [Binary values](guide/binary-values.md).
 

{redis_lua_py-0.5.1 → redis_lua_py-0.7.0}/docs/installation.md

@@ -21,6 +21,10 @@ own script machinery, which this library defers to rather than reimplementing.
 Anything redis-py can talk to, this can run against: a standalone server, a
 cluster, Sentinel, or an in-process [fakeredis](guide/testing.md).
 
+[coredis](https://github.com/alisaifee/coredis) clients work as well, and are
+tested against, but coredis is not a dependency: install it yourself. See
+[Async](guide/async.md#coredis).
+
 ## For testing
 
 [fakeredis](https://github.com/cunla/fakeredis-py) embeds a real Lua

{redis_lua_py-0.5.1 → redis_lua_py-0.7.0}/docs/reference/api.md

@@ -112,6 +112,9 @@ script(client, /, *positional, **keyword) -> Awaitable[R]   # async client
 | `args` | `tuple[str, ...]` | everything else, in `ARGV` order |
 | `variadic_key` | `str \| None` | the `list[Key]` parameter, which fills the rest of `KEYS` |
 | `variadic_arg` | `str \| None` | the list parameter that fills the rest of `ARGV` |
+| `param_annotations` | `tuple[str \| None, ...]` | each parameter's annotation as written, in `params` order |
+| `return_annotation` | `str \| None` | the return annotation as written |
+| `keyword_only` | `tuple[str, ...]` | the parameters declared after a bare `*` |
 | `doc` | `str \| None` | the function's docstring |
 | `source` | `str` | where it was defined, repo-relative |
 
@@ -227,8 +230,9 @@ package at runtime. See
 [Shipping without the dependency](../guide/build-time.md). Every function takes
 the module as a module object or a dotted name, and `out` as a path:
 
-- ending in `.py`, for one module holding every script as a string constant
-  and importing nothing
+- ending in `.py`, for one module importing only the standard library, with a
+  typed function per script, called the way the `@script` is, and its Lua as a
+  string constant
 - anything else, for a directory with one `.lua` file per script
 
 ### `codegen.generate`

{redis_lua_py-0.5.1 → redis_lua_py-0.7.0}/docs/reference/errors.md

@@ -4,11 +4,11 @@ Every error this package raises carries a caret under the line at fault, and a
 hint saying what to write instead.
 
 ```
-chained comparisons are not supported
+math.log() with a base is not supported
   File "/srv/app/limits.py", line 12
-    if 0 < n < limit:
-       ^
-  hint: Split 'a < b < c' into 'a < b and b < c'.
+    buckets = math.log(n, 2)
+              ^
+  hint: Lua 5.1's math.log takes no base; divide by math.log(base) instead.
 ```
 
 ## The hierarchy

{redis_lua_py-0.5.1 → redis_lua_py-0.7.0}/docs/reference/lua-vs-python.md

@@ -23,22 +23,27 @@ Lua tables are 1-based. `items[0]` compiles to `items[1]`. Write Python indices
 and let the compiler shift them.
 
 A dict key must not be shifted, and Lua cannot tell a list from a dict. So the
-compiler looks at the subscript:
+compiler looks first at what is subscripted. A dict is indexed by its keys as
+they are, integer keys included, and a list's index is shifted by one. When
+that is not known, it looks at the subscript:
 
 - a string literal, or a value known to be a string, is used as it is;
 - an integer literal, or a value known to be a number, is shifted by one;
 - anything else goes through a small `__key` helper, which shifts numbers and
   leaves everything else alone, at runtime.
 
-A value is known to be a string or a number from its annotation, a literal,
-the builtin or method that produced it, a `range()` or `enumerate()` loop
-variable, or every assignment to the name agreeing. Integer keys in a dict
-are treated as positions; use string keys.
+A value's type is known from its annotation, a literal, the builtin, method or
+operator that produced it, a `range()` or `enumerate()` loop variable, or
+every assignment to the name agreeing. So after `counts = {}`, `counts[0]` is
+the key `0`. A table that comes from elsewhere -- a Redis reply,
+`cjson.decode`, a helper's parameter -- is not known, and an integer subscript
+on it is taken to be a position.
 
 `items[-1]` compiles to `items[#items]`, which needs a name to count back from.
 Indexing a string gives a one-character string, as it does in Python, through
-`string.sub`. Slices, `v[i:j]`, work on lists and strings, with negative and
-missing bounds; a slice with a step is refused.
+`string.sub`. Slices, `v[i:j]` and `v[i:j:k]`, work on lists and strings, with
+negative and missing bounds, and bounds are clamped exactly as Python clamps
+them. A negative step walks backwards, so `word[::-1]` reverses.
 
 ## Assignment scope is closed
 
@@ -50,8 +55,10 @@ the top of the script, so it does not silently read back `nil`.
 
 Lua's `+` is only arithmetic. It will add `"1" + "2"` to `3`. So `+`
 compiles to Lua's `..` wherever either side is known to be a string, as
-above, and `"=" * n` to `string.rep`. Where neither side is known, `+` stays
-arithmetic; use an f-string to concatenate two values of unknown type.
+above, to Lua's `+` wherever either side is known to be a number, and
+`"=" * n` to `string.rep`. Where neither side is known, as with two Redis
+replies, a small `__add` helper decides at runtime: two strings are joined,
+two lists are joined into a new list, and anything else is added.
 
 The string methods compile to Lua's string library, and to small helpers where
 Python means something Lua's own functions do not:
@@ -60,7 +67,9 @@ Python means something Lua's own functions do not:
   substring. `string.find` would read `.` as a pattern.
 - **`strip`, `lstrip` and `rstrip`** strip whitespace, and take no argument.
 - **`x in s`** is a substring test on a string. On a list it is an element test;
-  on a dict it is a key test.
+  on a dict it is a key test. A table whose type is not known, such as a
+  decoded JSON value, is taken to be a dict when any of its keys is not a list
+  position, and a list otherwise.
 
 `"%s: %d" % (name, n)` and f-string format specs such as `{price:8.2f}` compile
 to `string.format`. Width, precision, sign and zero padding are supported. A
@@ -88,8 +97,10 @@ becomes the same kind of function, because `c and a or b` is wrong whenever
 `.items()`, `.keys()` and `.values()` compile to Lua's `pairs()`, which visits
 entries in no fixed order. Sort the result if the order reaches the caller.
 
-Iterating a dict directly with `for k in d` walks its array part, which a dict
-does not have, so the loop never runs. Say `.keys()`.
+`for k in d` walks the keys of a dict the compiler knows to be one, as
+`.keys()` does, and `len(d)` counts them. On a table whose type is not known,
+say `.keys()`: there, `for k in d` and `len(d)` see only list positions, which
+a dict does not have.
 
 ## Redis replies are flat lists, not dicts
 
@@ -149,7 +160,10 @@ kept, whether or not something catches it.
 
 ## A loop variable does not outlive its loop
 
-Unlike in Python.
+Unlike in Python. Lua also gives each step of a loop a variable of its own,
+which a function defined inside the loop would keep, where in Python every
+step shares one. So a `lambda` or a helper function that reads a loop variable
+is refused; pass the value in as a parameter instead.
 
 ## A nil inside a returned table truncates the reply
 

{redis_lua_py-0.5.1 → redis_lua_py-0.7.0}/docs/reference/supported-subset.md

@@ -13,12 +13,14 @@ language with a faithful Lua meaning is accepted.
   `assert`.
 - **Loops:** `for ... in` over a table, `range()`, `enumerate()`, or a dict's
   `.items()`, `.keys()` and `.values()`, binding a name or a tuple of names.
-- **Helper functions** defined with `def` at the top level of the body. They
-  can call each other and themselves.
-- **Expressions:** comparisons; arithmetic; `in` and `not in`; `and`/`or`, and
-  `a if c else b`, both as values; list and dict literals.
-- **Subscripts:** indices, dict keys, negative literal indices on a name, and
-  slices without a step, of lists and strings.
+- **Helper functions** defined with `def` at the top level of the body, and
+  `lambda` wherever an expression can go. They can call each other and
+  themselves, and be passed to a helper that calls them.
+- **Expressions:** comparisons, chained ones such as `0 < n <= limit`
+  included; arithmetic; `in` and `not in`; `and`/`or`, and `a if c else b`,
+  both as values; list and dict literals.
+- **Subscripts:** indices, dict keys of any type, negative literal indices on
+  a name, and slices of lists and strings, with a step or without.
 - **Strings:** f-strings with format specs; `%` formatting; `+` and `*` on a
   string; `str.join`, `upper`, `lower`, `strip`, `lstrip`, `rstrip`,
   `startswith`, `endswith`, `find`, `split` and `replace`.
@@ -37,11 +39,11 @@ Everything else raises
 with a caret under the line at fault:
 
 ```
-chained comparisons are not supported
+math.log() with a base is not supported
   File "/srv/app/limits.py", line 12
-    if 0 < n < limit:
-       ^
-  hint: Split 'a < b < c' into 'a < b and b < c'.
+    buckets = math.log(n, 2)
+              ^
+  hint: Lua 5.1's math.log takes no base; divide by math.log(base) instead.
 ```
 
 Failing at import, loudly, is deliberate. A body that looks like Python but is

{redis_lua_py-0.5.1 → redis_lua_py-0.7.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "redis-lua-py"
-version = "0.5.1"
+version = "0.7.0"
 description = "Write Redis Lua scripts as real Python functions, not strings."
 readme = "README.md"
 requires-python = ">=3.10"
@@ -41,6 +41,9 @@ dev = [
     "zensical>=0.0.61",
     # typing.assert_type, for tests/test_typing.py, arrived in Python 3.11.
     "typing_extensions>=4.2; python_version < '3.11'",
+    # Tested against, never required: coredis shapes a command differently
+    # from redis-py, and tests/test_coredis.py runs the same scripts through it.
+    "coredis>=6.9",
 ]
 
 [build-system]
@@ -77,8 +80,9 @@ select = ["E", "F", "I", "UP", "B", "SIM", "RUF", "N", "C4", "PT"]
 python_version = "3.10"
 strict = true
 # test_typing.py carries assert_type() claims about what a call returns, which
-# are only worth anything if mypy actually reads them.
-files = ["src", "tests/test_typing.py"]
+# are only worth anything if mypy actually reads them. generated_scripts.py is
+# codegen output, checked in so that strict mode reads what adopters ship.
+files = ["src", "tests/test_typing.py", "tests/generated_scripts.py"]
 mypy_path = "tests"
 
 # A script body returns Lua-side values, whose Python type is Any by

{redis_lua_py-0.5.1 → redis_lua_py-0.7.0}/src/redis_lua_py/__init__.py

@@ -67,7 +67,7 @@ __all__ = [
     "script",
 ]
 
-__version__ = "0.5.1"  # x-release-please-version
+__version__ = "0.7.0"  # x-release-please-version
 
 
 @overload