On Thu, Mar 7, 2019 at 2:51 PM Inada Naoki <songofaca...@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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
