Allows specification of a prefix for error sources

[funkyfuture]

This makes the output more meaningful in case one checks several documents and
aggregates their errors.
Also changes the type and format of list-item-index to match Python's index-
syntax.

[nicolaiarocci]

This makes the output more meaningful in case one checks several documents and
aggregates their errors.

Looks good.

Also changes the type and format of list-item-index to match Python's index-
syntax.

This I find it less useful than a direct list index. Can you elaborate on why

{'list_of_strings: {'[1]': 'error description'}}

is more useful than

{'list_of_strings: {1: 'error description'}}

Looks to me like, in most use cases, the former would require some extra parsing.

[funkyfuture]

the intention is to make the output better understandable for end-users. and propably my idea is only suited for those familiar with programming. in this regard, the index should actually be incremented by 1.

so, i propose to prefix it wirth item #:

{'list_of_strings': {'item #1': 'error description'}}

as you can see this is accomplished by simple int-to-string-conversion and string-operations. of course it all depends also how the client code handles the errors. i'd prefer it to be string only. but uses where an integer is prefered are thinkable.

so, maybe it would be a start to add a boolean flag human_readable to Validator.__init__.

[nicolaiarocci]

I see. Making it more readable for humans is probably a good idea. I also like making it configurable with a human_readable property, but maybe that's overkill.

[nicolaiarocci]

Would you please split this into two separate PRs, one for prefixes and another for list items? I know they're quite trivial, but it helps making project history a little more linear.

[funkyfuture]

yep, that is the plan.

my idea atm is to introduce optional error-output-handlers. with one example-implementation for human-readable-output (incl. the list-item-thing and #90) and one that stores errors in a yaml-file.

but i want to complete some other milestones on the project that makes use of it.

[funkyfuture]

i close this PR in favor of the proposed trail in #93