Resolve non-keyword arguments

[frankenjoe]

Closes #57

Solved by converting positional arguments to keyword arguments.

[hagenw]

You have to add the following to tests/requirements.txt:

# To avoid https://github.com/tholo/pytest-flake8/issues/87
flake8 <5.0.0

[frankenjoe]

Yes, I created https://github.com/audeering/audobject/pull/59

[codecov[bot]]

Codecov Report

Merging #58 (01b72c2) into master (cba43a1) will not change coverage. The diff coverage is 100.0%.

Impacted Files	Coverage Δ
audobject/core/decorator.py	100.0% <100.0%> (ø)

[frankenjoe]

@hagenw it's ready for review now

[hagenw]

Can this have any unwanted consequences?

Let's say you have stored an object with an older versions and args where stored as args in the YAML, but now after loading they are marked as kwargs in the object/class. Or is there no differentiation inside the object after loading it?

[frankenjoe]

When you load an object directly from a YAML all the arguments are passed as keyword arguments. Only when the object then calls the constructor of its super class it can happen that you call it with positional arguments (see example in #57). So it's a rather rare case, which is the reason we did not run into this issue before.

[frankenjoe]

In fact, we should maybe always convert positional arguments to keyword arguments and not only if a resolver is applied. Then we always create objects in the same way - independent if we load it directly or indirectly through a call to super().

Btw: always loading by keyword has the advantage that the order in which the arguments are stored in the YAML file doesn't matter.

[hagenw]

Great, I also think it's better to do the conversion independent of the resolver.