[Python-Dev] configparser: should optionxform be idempotent?

[Paul Moore]

On Thu, 7 Mar 2019 at 10:06, Inada Naoki <songofacandy at gmail.com> wrote:
>
> On Thu, Mar 7, 2019 at 6:57 PM Paul Moore <p.f.moore at gmail.com> wrote:
> >
> > I'm not keen on the term "idempotent" here - I wasn't at all clear
> > what it was intended to convey. But from looking at the bug report, I
> > see that it basically means "optionxform should be a function which,
> > when applied more than one time to a value, returns the same result as
> > if it had been applied once only".
>
> You're right.  "idempotent" is technical (or mathematical) jargon.
> When f(x) satisfies "f(x) == f(f(x)) for all x" restriction, f(x) is idempotent.

Thanks. I know what the term means, at least in a mathematical sense -
the computing sense is slightly different (in a subtle way that may
not be relevant here - see
https://stackoverflow.com/questions/1077412/what-is-an-idempotent-operation).

> > I'd look at the question the other way round. If we *did* insist that
> > optionxform has to be "idempotent", how would we recommend that the
> > person who reported the bug achieved the result he's trying to get?
> > lambda x: x if x.startswith("(") and x.endswith(")") else "(" + x +
> > ")"? That seems a bit fiddly.
>
> In this case, we recommend not using optionxform to wrap name with
> "()" implicitly.  Use wrapped name explicitly instead.
>
> e.g. cfg["section"]["(name)"] = "value"
>
> It's very simple.

That argument could be used for any use of optionxform, though -
instead of using the default optionxform, use explicitly-lowercased
values everywhere instead.

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