[Python-Dev] configparser: should optionxform be idempotent? (original) (raw)
Inada Naoki songofacandy at gmail.com
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 ]