Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kwarg different between StrictRedis init/from_url #510

Closed
ericrasmussen opened this issue Jul 4, 2014 · 2 comments
Closed

kwarg different between StrictRedis init/from_url #510

ericrasmussen opened this issue Jul 4, 2014 · 2 comments

Comments

@ericrasmussen
Copy link

Somewhere between redis-py 2.7 and redis-py 2.10, the StrictRedis.__init__ and
StrictRedis.from_url APIs diverged. They now take different keyword arguments
for errors and encoding_errors.

Is this a bug that will be fixed in later versions, or is it an intentional API change? I maintain pyramid_redis_sessions and will pin it to a version < 2.10 for now, but if it's an intentional change you plan to keep going forward, I'd like to know so I can accommodate the two different APIs.

The example below works on 2.7, and errors on 2.10:

import redis

if __name__ == '__main__':
    # invoking StrictRedis directly is fine
    r1 = redis.StrictRedis(errors='strict')
    r1.set('foo', 'bar')
    print r1.get('foo')

    # in redis-py 2.10, from_url now expects keyword `encoding_errors` instead
    # of errors...
    r2 = redis.StrictRedis.from_url('redis://localhost:6379/0', errors='strict')

    # ...but you don't find out until you access it and it raises TypeError
    print r2.get('foo')
@andymccurdy
Copy link
Contributor

@ericrasmussen Thanks for letting me know. It was an oversight. charset and errors can be passed again, but will now issue deprecation warnings. encoding and encoding_errors are preferred.

@ericrasmussen
Copy link
Author

That was fast -- thanks so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants