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

Possible RecursionError in KeywordResult._handle_return_value() #57

Open
tw39124-1 opened this issue Dec 11, 2019 · 0 comments
Open

Possible RecursionError in KeywordResult._handle_return_value() #57

tw39124-1 opened this issue Dec 11, 2019 · 0 comments

Comments

@tw39124-1
Copy link

KeywordResult._handle_return_value() calls itself as part of a list-comprehension if ret does not get handled by the initial if-statements:

def _handle_return_value(self, ret):
    if isinstance(ret, (str, unicode, bytes)):
        return self._handle_binary_result(ret)
    if isinstance(ret, (int, long, float)):
        return ret
    if isinstance(ret, Mapping):
        return dict((self._str(key), self._handle_return_value(value))
                    for key, value in ret.items())
    try:
        return [self._handle_return_value(item) for item in ret]
    except TypeError:
        return self._str(ret)

However, in this case ret is an object provided by a library, which happens to return itself when __getitem__ is called. _handle_return_value then enters an infinite recursion, which eventually causes the interpreter to raise a RecursionError. Should the list comprehension be inside an if-clause which checks that the object is actually a list-like object?

To get around this for now I am pickling and base64-encoding the object to a string and returning that, but that means I have to decode and de-pickle it back into an object on the client side. It would be nice if I didn't have to do this and could just return an object from my remote keyword without this issue.

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

1 participant