Add option to consider iterables as dicts

[sgenoud]

Sometimes a nested iterable can actually be considered as a dictionary. This PR adds the possibility to define a function that will attempt to extract the key from the items themselves.

def name_is_key(item, **kwargs):
    if not hasattr(item, 'get'):
        return None

    return item.get('name')

t1 = [
    {'name': 'bim', 'value': 3},
    {'name': 'bam', 'value': 4},
]
t2 = [
    {'name': 'bam', 'value': 4},
    {'name': 'bim', 'value': 4},
]
ddiff = DeepDiff(t1, t2, key_extractor=name_is_key)
print(ddiff)

will print out:

{
    "values_changed": {
        "root['bim']['value']": {
            'new_value': 4,
            'old_value': 3
        }
    }
}

Note that the PR solves a sub category of the problems raised in #29

[coveralls]

Coverage remained the same at 100.0% when pulling 3e5e386 on sgenoud:feature/iterable-key-extractor into 56034a4 on seperman:master.

[RafiC92]

@seperman is this option available? can you please expand on how to use it in a larger nested list of dictionaries?

Thank you.

[RunOrVeith]

I would also like to see this in the main release!

[seperman]

@sgenoud I'm sorry it has taken one and half year to look at your PR. There are some merge conflicts. I don't think I can ask you after 1.5 year to change your PR. Gonna copy paste your code and do some modifications. Then will add your name to the authors list. Thank you.

[seperman]

I gave this feature some thought. I think it should be addressed in a more holistic way so it solves a group of problems which have to do with transformations before starting to diff objects. I'm going to add a feature to allow passing custom transformations or choosing from built-in ones. I'm gonna use the transformation function you built (__create_dict). I'm not going to merge this PR. But will keep you posted once I implement the transformation functionality. Thank you very much again for your contribution.

[sgenoud]

I'm sorry it has taken one and half year to look at your PR.

Don't be sorry, this is the beauty of open source – everyone has a limited amount of time, and working from a branch is no big deal.

I think it should be addressed in a more holistic way so it solves a group of problems which have to do with transformations before starting to diff objects.

For my two cents here, this sounds like a good implementation strategy, but I would go for exposing the purpose built transformation as their own arguments.
It becomes easier to document and understand, you only need to learn how transformations work when you need them (even if you use it for something else).

I do not use this code anymore, I'll probably ping people at my former company when you are done.

Thanks for building the module in the first place!