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

Recursively normalize DictParameter #2115

Merged
merged 4 commits into from
May 21, 2017

Conversation

jonathan-ostrander
Copy link
Contributor

Description

This recursively calls normalize on Mappings and lists when calling DictParameter.normalize. Also, makes OrderedFrozenDict and DictParameter.DictParamEncoder private, as requested by @Tarrasch.

Motivation and Context

Fixes issue #2094.

Have you tested this? If so, how?

Added a test, but am open to suggestions of better tests.

Copy link
Contributor

@Tarrasch Tarrasch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can merge this as I see it as "strict improvement" (not the least in documentation), but I believe I have spotted a bug. :)


I'm not sure, but perhaps you have to create a helper like _recursively_freeze() which doesn't use anything from Parameter or normalize(). That's probably how I would do it, but this is just a suggestion. :)

if isinstance(v, Mapping):
return self.normalize(v)
elif isinstance(v, list):
return ListParameter().normalize(v)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this work if a list contains a dict or a list?

@Tarrasch
Copy link
Contributor

By the way, it seems like the failed test weren't just flukes. I think either code or testcode needs to be updated/fixed.

@jonathan-ostrander
Copy link
Contributor Author

jonathan-ostrander commented May 19, 2017 via email

Copy link
Contributor

@Tarrasch Tarrasch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, I'm trying to reproduce that behavior but 3.4 and 3.5 are behaving as expected for me.

It's probably because the traversal orders of dicts are random.


By the way, why don't you add a test case for the code that you fixed with your latest commit? TDD is a sane practice at least when fixing bugs. :)

@@ -917,7 +928,7 @@ def normalize(self, x):
:param str x: the value to parse.
:return: the normalized (hashable/immutable) value.
"""
return tuple(x)
return _recursively_freeze(x)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should still be tuple() I think, or do we say anywhere a "bigger" structure is allowed?

Copy link
Contributor Author

@jonathan-ostrander jonathan-ostrander May 19, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The documentation says <JSON string> so I think that implies it can be a list containing additional lists or Mappings

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is sort of overkill for a very specific use case though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why on earth is it a JSON Object ... oh well then. Looks good to me.

@Tarrasch Tarrasch merged commit 447489a into spotify:master May 21, 2017
@Tarrasch
Copy link
Contributor

Tarrasch commented May 21, 2017

Big thanks! Such an improvement.

But as for issue #2094, I'm not 100% confident this solved that issue. Let's ping the issue author in that 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

Successfully merging this pull request may close these issues.

3 participants