[Python-Dev] configparser: should optionxform be idempotent?
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
> > 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.