fix: WRONGTYPE checks for LLEN/HGETALL and full negative-index support in LRANGE

[biswajeetdev]

What

Three Redis spec compliance fixes caught while testing with redis-cli:

Bug 1 — LRANGE only handled stop == -1

Redis supports full negative-index semantics: LRANGE key 0 -1 returns all elements, LRANGE key -3 -1 returns the last three. The previous implementation special-cased only stop == -1 and passed all other negative values straight to Python slice, producing silently wrong results:

LRANGE mylist -3 -1   # expected: last 3 items
                       # got: [] (Python slice with unresolved negative start)

Fixed with proper translation using length + index before slicing.

Bug 2 — LLEN missing WRONGTYPE guard

Calling LLEN on a key that holds a string or hash would silently return len(string) or len(dict_keys) instead of the standard Redis WRONGTYPE error. Added isinstance(lst, list) guard.

Bug 3 — HGETALL could crash with AttributeError

store.get(key) or {} falls through to {} for falsy values, but for a non-empty list the stored value is returned as-is. Calling .items() on a list raises AttributeError, which is not caught by the outer except (ValueError, IndexError) — killing the client connection. Added explicit isinstance(h, dict) check.

Test

# Start server
python server.py

# In another terminal
redis-cli -p 6380

# Negative index
RPUSH nums a b c d e
LRANGE nums 0 -1    # all 5
LRANGE nums -3 -1   # c d e

# WRONGTYPE
SET mystr "hello"
LLEN mystr          # -ERR WRONGTYPE ...
HGETALL mystr       # -ERR WRONGTYPE ...