(original) (raw)
On Thu, Mar 7, 2019 at 2:51 PM Inada Naoki <songofacandy@gmail.com> wrote:
Hi, all.
I came from https://bugs.python.org/issue35838
Since there are no "expert" for configparser in
Expert Index, I ask here to make design decision.
There is lukasz.langa in the expert index for configparser at https://devguide.python.org/experts/#stdlib and that's why I deferred to them.
The default behavior of CofigParser.optionxform
is str.lowercase(). This is used to canonicalize
option key names.
The document of the optionxform shows example
overrides it to identity function \`lambda option: option\`.
https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.optionxform
BPO-35838 is issue about optionxform can be called twice
while ConfigParser.read\_dict().
If optionxfrom is not idempotent, it creates unexpected option
name.
https://bugs.python.org/issue35838#msg334439
But even if all APIs calls optionxform exactly once, user may
read option name and value, and write updated value with same name.
In this case, user read option name already optionxform-ed
(canonicalized). So non-idempotent optionxform will break
option name.
So what should we do about optionxform?
a) Document "optionxform must be idempotent".
I also feel this is restrictive since wrapping keys with () looks like a valid use case to me.
b) Ensure all APIs calls optionxform exactly once, and document
"When you get option name from section objects, it is already
optionxform-ed. You can not reuse the option name if
optionxform is not idempotent, because optionxform will be
applied to the name again."
I prefer (a) to (b) because it's simple and easy solution.
I initially preferred (b) while read\_dict is one case. As you have mentioned in the tracker there are various scenarios where the transform is done and stored in the underlying internal dict and then while setting one section key to another it might apply it again. Also I am afraid there is less test coverage for optionxform itself so there could be more scenarios to cover increasing the complexity.
--
Regards,
Karthikeyan S