Case-insensitive parsing and validation.

[robertodr]

As pointed out by @stigrj it would be good to not force case-sensitivity upon the users. I see some options:

1. Do it before we parse. This would mean the programmer using the library has to normalize the case of the input file and the validation template has to adhere to this choice. That is, if normalization is uppercase (lowercase), then validation template use uppercase (lowercase).
2. As point 1, but we add an option to the api.lex (and expose it in the CLI). Something like --case upper (--case lower)
3. We let the grammar take care of case normalization, by adding a parse action to the various tokens. In case we change the parsing library (from pyparsing to lark, for example) this will not carry through.
4. We do case normalization at the validation level. I think this is the most invasive option of all.

[stigrj]

2. 👍

[bast]

I agree with 2.

[robertodr]

Noting this here, as it might be helpful: https://docs.python.org/3/library/stdtypes.html#str.casefold

[robertodr]

Does it make sense to you that the case of quoted strings should be preserved? The way Getkw works, you can have quoted and unquoted strings. The latter can only look like valid C user tokens (first character can be an underscore or an alphabetic chars, followed by more underscores and alphanumeric chars) whereas the former can be almost anything (unicode too, I think) Most importantly, quoted string can contain slashes, so that this is the format one should use to specify file paths. I'd expect file paths to always be intended to be case-sensitive, hence my question.

[bast]

I agree that changing case of paths is dangerous. Also until now I did not realize that we wanted to possibly normalize everything - somehow I imagined that we only normalize keys but not values.

[robertodr]

Yeah, it's thorny. Are all of these acceptable?

Functional = B3LYP
functional = b3lyp
FunCtioNAL = b3LYP

[bast]

Every time I saw case insensitivity as user (e.g. Fortran, old OS X file system (?)), I thought: "wow what a terrible idea!" - but I guess we can offer the possibility.

[bast]

How will this work:

datapath1 = /home/user/doNotNormalizeMe
datapath2 = "/home/user/doNotNormalizeMe"

[robertodr]

The current grammar will not be able to parse the former.

[bast]

How about we only offer ignore-casing of keys? But we preserve values?

[stigrj]

How about this

  a_bool = True
  another_bool = false

Is it defined in the grammar what to accept?

[robertodr]

@stigrj All of these are valid for booleans as caseless literals already.

truthy = ["TRUE", "ON", "YES", "Y"]
"""List[str]: List of true-like values."""
falsey = ["FALSE", "OFF", "NO", "N"]
"""List[str]: List of false-like values."""

@bast I think I would still like b3lyp to be as valid as B3LYP though. Regarding floating point numbers, only caseless E is recognized now. D can be arranged too, but I'd rather not encourage using D...

[bast]

Good point about the booleans, this is a frequent papercut. Also scientific notation floats should allow ignore-case "D" and "E".