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

Fix path behaviour for set_ #214

Merged
merged 5 commits into from
Jan 28, 2024
Merged

Conversation

DeviousStoat
Copy link
Contributor

fixes #213

The default type when setting a missing key is usually given by the PathToken built in to_path_tokens.
However this function is incomplete and only builds a list of PathTokens if the path is a string.

The issue here is that that line sets the default type to list if the object to update is not a dict.
And as stated above, when we have a path as a list to_path_tokens just returns the list and we don't have any information about the default factory, we just default to list.
So when we create the first list and try to update it we expect an index.

This PR updates the to_path_tokens function to be more general and build the list of PathToken even for a list.

The added pragma: no cover are there because this case should now be impossible to reach, the only case where the tokens are not PathTokens is when the path is only 1 non string value and we go directly to the end case as the for loop only iterates on the initial values.

@coveralls
Copy link

coveralls commented Jan 19, 2024

Coverage Status

coverage: 100.0%. remained the same
when pulling c548717 on DeviousStoat:fix-set_
into 2a2fb8e on dgilland:develop.

Comment on lines 2422 to 2425
if isinstance(token, PathToken):
key = token.key
default_factory = pyd.get(tokens, [idx + 1, "default_factory"], default=default_type)
else:
else: # pragma: no cover
Copy link
Owner

Choose a reason for hiding this comment

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

If the else case is no longer valid and isinstance(token, PathToken) is always true, then I think we could remove the if-statement and just have whatever is under the main if section.

Unless there was a reason to leave them in?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah makes sense. I removed them.

I left them just to be safe, but I guess if it happens it would probably be a rare edge case. The test cases cover a lot of cases and every passes so it should be safe enough.

Copy link
Owner

Choose a reason for hiding this comment

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

would probably be a rare edge case

From looking at the code, the tokens are from to_path_tokens() which always returns a PathToken list, right? So should never be any other type. Unless I missed something in to_path_tokens() where a different type could be included?

Copy link
Contributor Author

@DeviousStoat DeviousStoat Jan 27, 2024

Choose a reason for hiding this comment

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

to_path_tokens can return something else than a PathToken if it is a single element like "0" or "some_key".
But I guess we should probably make to_path_tokens always return a list of PathToken all the time. It would be more consistant and easier to reason about.
I added a commit with it. Let me know what you think

@DeviousStoat
Copy link
Contributor Author

Lint fails in CI on files I didn't touch and everything passes localy. Not sure what's going on. Maybe we can just try rerunning it?

@dgilland
Copy link
Owner

Lint fails in CI on files I didn't touch and everything passes localy. Not sure what's going on. Maybe we can just try rerunning it?

Latest version of black made some changes to the formatting and required some flake8 ignores on certain rules. Rebase with develop to get those changes and lint should be good.

Copy link
Owner

@dgilland dgilland left a comment

Choose a reason for hiding this comment

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

Nice work!

@dgilland dgilland merged commit a52dfe7 into dgilland:develop Jan 28, 2024
12 checks passed
@DeviousStoat DeviousStoat deleted the fix-set_ branch January 28, 2024 02:31
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.

Unexpected difference in path behavior for set_() when accessing attribute of object
3 participants