BUG: redis-py 1.3.4 with a redis-1.3.4 server - keys response parsed incorrectly

[SJD]

It looks like the protocol response from the server has changed slightly for the keys function (and possibly others untested). Where our old servers (1.2.1) used to say this;

KEYS *
$3
foo

... the new server (1.3.4) says this;

KEYS *
*1
$3
foo

I think it is preceding the #bytes with the #responses, in this case 1. What this means for the lambda called from RESPONSE_CALLBACKS for keys, is that it gets a list and attempts to split it (because it is expecting a string)

'KEYS' : lambda r: r and r.split(' ') or [],

To see it in action, start up a 1.3.4 server (got mine from github), crank up a python interpreter, and fire away;

r.info()
{'bgrewriteaof_in_progress': 0, 'uptime_in_days': 0, 'multiplexing_api': 'epoll', 'last_save_time': 1268698696, 'redis_version': '1.3.4', 'connected_clients': 1, 'hash_max_zipmap_value': 512, 'vm_enabled': 0, 'role': 'master', 'total_commands_processed': 30, 'total_connections_received': 9, 'used_memory_human': '523.43K', 'blocked_clients': 0, 'process_id': 19110, 'connected_slaves': 0, 'db0': {'keys': 1, 'expires': 0}, 'arch_bits': 64, 'hash_max_zipmap_entries': 64, 'bgsave_in_progress': 0, 'used_memory': 535993, 'uptime_in_seconds': 4054, 'changes_since_last_save': 1}

r.keys('*')
[]

r.set('foo', 'zoo')
True

r.keys('*')
Traceback (most recent call last):
File "", line 1, in
File "build/bdist.linux-x86_64/egg/redis/client.py", line 440, in keys
File "build/bdist.linux-x86_64/egg/redis/client.py", line 284, in format_inline
File "build/bdist.linux-x86_64/egg/redis/client.py", line 220, in execute_command
File "build/bdist.linux-x86_64/egg/redis/client.py", line 215, in _execute_command
File "build/bdist.linux-x86_64/egg/redis/client.py", line 269, in parse_response
File "build/bdist.linux-x86_64/egg/redis/client.py", line 181, in
AttributeError: 'list' object has no attribute 'split'

I'm in the process of porting some code from 0.6.3(?) because you now have pipelining (yay), but this is a bit of a bu99er because I use the keys call a lot. It is possible that other calls I haven't come across could be affected by this variation in protocol response.

Cheers
Sam

[SJD]

Erg, I see you have already fixed this. Sorry for the noise =\

[andymccurdy]

No worries. I would caution you though -- keys() isn't an efficient operation on the redis server side. It's literally scanning all keys to check if the particular pattern matches each one. If you can figure out how to group your keys, perhaps in a number of sets, then use SMEMBERS to get all the keys from a specific set, you'd be much better off.

[SJD]

Ahh yes. At the client end I use redis as a kind of volatile configuration/ IPC type instance on a host with a collection of processes sharing the instance. It means there are less than a hundred keys of varying types - even less now with hash support. Mostly it is depth rather than breadth. Looking forward to hkeys, hvalues, and hitems or whatever they get called =]