Confusing option setting for the parser

[omangin]

Some options have to be set when the parser object is created like common_strings because they are treated in the __init__, others can be changed until the parsing occurs by doing some parser.option = new_value.

This behavior is confusing and should be improved to convey more clearly what the parser object does and retain. It is not clear which approach to this is best: loading default strings could be delayed to just before parsing, or setting options directly could be deprecated.

See also #222.

[tqbl]

Another option is to add a setter function for common_strings that calls load_common_strings(). I think this is better than loading the strings before parsing, although it's a little ugly syntactically.

[omangin]

The issue then is that doing

parser.common_strings = True
parser.common_strings = False

would not behave as expected since the second one would have no effect. We could then raise an exception if on attempts to set the value to False but the point is that the semantics of the option (set at the creation of the parser and not changeable afterwards) is not matching the semantics of how it is set.

[tqbl]

True, but wouldn't this also be a problem if you loaded the strings before parsing? In principle, the user could set it to false after parsing once and then try to parse again.

Without fully checking the source code, adding self.bib_database.strings = OrderedDict() for the second statement should work. It would override strings added by previous parse actions, but shouldn't lead to errors.

[omangin]

Indeed but it requires the user to know and interact with what is supposed to be implementation details.

Here I would say that if we want to allow that we should provide a method for resetting the string database instead.

[MiWeiss]

fixed in v2