[Python-Dev] configparser: should optionxform be idempotent?
Inada Naoki
songofacandy at gmail.com
Thu Mar 7 05:06:31 EST 2019
More information about the Python-Dev mailing list
Thu Mar 7 05:06:31 EST 2019
- Previous message (by thread): [Python-Dev] configparser: should optionxform be idempotent?
- Next message (by thread): [Python-Dev] configparser: should optionxform be idempotent?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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. > > 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. -- Inada Naoki <songofacandy at gmail.com>
- Previous message (by thread): [Python-Dev] configparser: should optionxform be idempotent?
- Next message (by thread): [Python-Dev] configparser: should optionxform be idempotent?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list