<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 7, 2019 at 2:51 PM Inada Naoki <<a href="mailto:songofacandy@gmail.com">songofacandy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, all.<br>
<br>
I came from <a href="https://bugs.python.org/issue35838" rel="noreferrer" target="_blank">https://bugs.python.org/issue35838</a><br>
Since there are no "expert" for configparser in<br>
Expert Index, I ask here to make design decision.<br></blockquote><div><br></div><div>There is lukasz.langa in the expert index for configparser at <a href="https://devguide.python.org/experts/#stdlib">https://devguide.python.org/experts/#stdlib</a> and that's why I deferred to them.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The default behavior of CofigParser.optionxform<br>
is str.lowercase().  This is used to canonicalize<br>
option key names.<br>
<br>
The document of the optionxform shows example<br>
overrides it to identity function `lambda option: option`.<br>
<a href="https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.optionxform" rel="noreferrer" target="_blank">https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.optionxform</a><br>
<br>
BPO-35838 is issue about optionxform can be called twice<br>
while ConfigParser.read_dict().<br>
If optionxfrom is not idempotent, it creates unexpected option<br>
name.<br>
<a href="https://bugs.python.org/issue35838#msg334439" rel="noreferrer" target="_blank">https://bugs.python.org/issue35838#msg334439</a><br>
<br>
But even if all APIs calls optionxform exactly once, user may<br>
read option name and value, and write updated value with same name.<br>
In this case, user read option name already optionxform-ed<br>
(canonicalized).  So non-idempotent optionxform will break<br>
option name.<br>
<br>
So what should we do about optionxform?<br>
<br>
a)  Document "optionxform must be idempotent".<br></blockquote><div><br></div><div>I also feel this is restrictive since wrapping keys with () looks like a valid use case to me.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
b) Ensure all APIs calls optionxform exactly once, and document<br>
   "When you get option name from section objects, it is already<br>
    optionxform-ed.  You can not reuse the option name if<br>
    optionxform is not idempotent, because optionxform will be<br>
    applied to the name again."<br>
<br>
I prefer (a) to (b) because it's simple and easy solution.<br></blockquote><div><br></div><div>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.<br></div></div><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Regards,<div>Karthikeyan S</div></div></div></div></div>