>
> That argument could be used for any use of optionxform, though -
> instead of using the default optionxform, use explicitly-lowercased
> values everywhere instead.
>
It can't be usable if the config format case-insensitive.
value = (cfg.get("section", "name") or cfg.get("section", "Name")
or cfg.get("section", "nAme") or cfg.get("section", "naMe")...)
> I still prefer option (b), allowing general functions for optionxform.
> However, I will say (and I should have said in my first mail) that
> this is a view based purely on theoretical considerations. I've never
> explicitly used optionxform myself, and none of my code would be
> impacted in any way regardless of the outcome of this discussion.
>
> Paul
If we choose (b), I think core developer must check test coverage for
optionxform before documenting non-idempotent optionxform
is allowed explicitly.
I don't have motivation for that because I never used configparser in such way.
The PR looks good to me for the particular case the issue describe.
So I will merge the PR without updating document when we chose (b).
But let's wait a few days for other comments.
Regards,
--
Inada Naoki <songofacandy at gmail.com>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4