Skip to content

Conversation

milanvdm
Copy link
Contributor

No description provided.

@milanvdm milanvdm requested a review from sv3ndk January 21, 2018 17:14
Copy link
Contributor

@sv3ndk sv3ndk left a comment

Choose a reason for hiding this comment

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

Thanks for the refactoring :)
A few comments, especially about mutating variables.



class Relations(object):
class OutgoingRelationships(object):
Copy link
Contributor

Choose a reason for hiding this comment

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

I like the addition of Outgoing, that indeed clarifies the direction.
However I would not use the term relationship in this class since that term has a specific meaning in the context of Trumania => I think that would cause a confusion between Relationship and OutgoingRelationship (maybe suggesting the later is a specific case of the former)

=> how about OutgoingRelations ?

return {key: merged_value(key) for key in keys}
if dict1 == dict2:
for k, v in dict1.items():
dict1[k] = value_merge_func(v, v)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need to call value_merge_func() ? why not just returning dict1 ? I just did a quick check, python's == seems to honor __eq__() on the dictionnary values => if == returns true, that means those dicts are equal and I think do not need to be merged

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If the merge function is for example add 1, you still need to apply the merge function.

for key_to_merge in keys_to_merge:
old_value1 = dict1.pop(key_to_merge)
old_value2 = dict2.pop(key_to_merge)

Copy link
Contributor

@sv3ndk sv3ndk Jan 22, 2018

Choose a reason for hiding this comment

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

Unless really proven to be necessary for optimisations reasons, I would discourage mutating dict1 and dict2 since this is a parameter we receive as argument.
This is because, from the point of view of the caller, the statement a = merge_2_dicts(b, c) is not expected to update b nor c, otherwise the method becomes hard to reason about and hard to use in more complex compositions.

I think that thanks to the order you put in return {**dict1, **dict2, **values_merged} (nice one, I didn't know that syntax :) ), the pop is actually not necessary since the priority is given to the values on the right => if we rephrase that for-loop as follows:

values_merged = {k: value_merge_func(dict1[k], dict2[k] for k in key_to_merge}

We obtain the equivalent logic.

What do you think ?


keys_to_merge = dict1_set.intersection(dict2_set)

if len(keys_to_merge) == 0 and value_merge_func is None:
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this should be if len(keys_to_merge) != 0

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.

2 participants