[Python-Dev] configparser: should optionxform be idempotent?
On Thu, Mar 7, 2019 at 2:51 PM Inada Naoki <songofacandy at 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
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`.
> BPO-35838 is issue about optionxform can be called twice
> while ConfigParser.read_dict().
> If optionxfrom is not idempotent, it creates unexpected option
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...