More precise field paths for collections

[brendonky18]

Is your feature request related to a problem? Please describe.
I have to parse a large configuration file, part of which is essentially a dictionary of structured objects. Currently if an error occurs while parsing one of these objects, dacite does not tell you which specific key the error occurred in, which can be annoying to hunt down when dealing with large dictionaries.

Describe the solution you'd like
When a DaciteFieldError is raised while building a member of a collection, update the field path to include a reference to which member the error occurred in. In the case of a dictionary or other mapping, this would be the key. In a Sequence-like collection (tuples and lists) this would be the index. This would make it akin to how pydantic represents these errors.

I already have a mocked-out version that we are using, so I would be happy to submit a PR if this is accepted.

[mciszczon]

Hi @brendonky18, thanks for creating the issue! This seems like a very much needed and overlooked feature. Please, feel free to submit a PR if you've got some work done already :)

[brendonky18]

Awesome, will do. When it comes to members of collections, is there a preference in how you think they should be represented in the path? The two possible options I can think of are using a dotted notation, as how it is done in pydantic, e.g. foo.bar.baz, or we could use brackets to indicate that it is a member of a collection foo[bar].baz. The latter option seems like a more elegant solution; however, it would require more logic when constructing the field path. With lists in particular, I think using brackets makes more sense, as foo[123].bar communicates that this is a member of a list as opposed to foo.123.bar.

[AlejandroUPC]

@brendonky18 came across, if I understood right I might be having a similar issue and wanted to look into giving this a shot, any progress on your end?

[m-aciek]

When it comes to members of collections, is there a preference in how you think they should be represented in the path?

I personally like foo[bar] more over foo.bar.

[brendonky18]

Hi @AlejandroUPC sorry about that, unfortunately I only have a half-baked solution but I probably won't be able to get around to actually fixing it for a while. If you're willing to take this on please don't let me stop you.