mikaelho

@FeodorFitsner, I can take this is you are happy with the approach that `src` accepts either a `str` or a file-like object?

My quick take is that converting it to base64 means that the file only comes from disk and then goes over the WebSocket ("2 transfers"), but with the asset approach...

Ok, so how about: src accepts str or file-like, and saves the file-like to assets, src_base64 accepts bytes or file-like to be base64 encoded, with warning in the docs about...

Is this a bug? The proposed change would a potential error in the order of applying patches to pass unnoticed. I understand why this feature could be desirable in some...

I believe I fully understand why this feature would be valuable for your company. My comment was due to the fact that I have discovered errors in my patching order...

I am not the maintainer, but personally I would welcome a keyword argument where the default is the existing behaviour, for backwards compatibility. In my experience pull requests here are...

Do you mean that it would consider different orders of keys as a difference to be reported?

Would make sense to have the option, given that CPython 3.6 dicts are ordered as well (even though "not to be relied upon").

I am confused by the statement: ”it can not detect changes in the order of elements”. Since: >>> list(dictdiffer.diff([1,2],[2,1])) [('change', [0], (1, 2)), ('change', [1], (2, 1))] Can you expand...

Now I explained it to myself. The ideal result, at least for some use cases, would be some kind of a ”swap” operation, instead of the two ”changes”.