osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]# [Python-Dev] configparser: should optionxform be idempotent?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

- Prev by Date:
**[Python-Dev] configparser: should optionxform be idempotent?** - Next by Date:
**[Python-Dev] configparser: should optionxform be idempotent?** - Previous by thread:
**[Python-Dev] configparser: should optionxform be idempotent?** - Next by thread:
**[Python-Dev] configparser: should optionxform be idempotent?** - Index(es):