[Python-Dev] configparser: should optionxform be idempotent? (original) (raw)

Paul Moore p.f.moore at gmail.com
Thu Mar 7 04:56:49 EST 2019

On Thu, 7 Mar 2019 at 09:21, Inada Naoki <songofacandy at gmail.com> wrote:

The document of the optionxform shows example overrides it to identity function lambda option: option. https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.optionxform

BPO-35838 is issue about optionxform can be called twice while ConfigParser.readdict(). If optionxfrom is not idempotent, it creates unexpected option name. https://bugs.python.org/issue35838#msg334439

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".

But even if all APIs calls optionxform exactly once, user may read option name and value, and write updated value with same name. In this case, user read option name already optionxform-ed (canonicalized). So non-idempotent optionxform will break option name.

So what should we do about optionxform? a) Document "optionxform must be idempotent". b) Ensure all APIs calls optionxform exactly once, and document "When you get option name from section objects, it is already optionxform-ed. You can not reuse the option name if optionxform is not idempotent, because optionxform will be applied to the name again." I prefer (a) to (b) because it's simple and easy solution.

I strongly prefer (b). I think the example given in the bug report is a reasonable thing to expect to work. I think that disallowing this usage is an arbitrary restriction that honestly doesn't have a good justification other than "it's easier for the implementation". It's obviously not a common requirement, otherwise the issue would have come up more often, but it's a reasonable one (after all, we don't require similar functions like the key argument to sorted() to conform to this restriction).

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.

If, however, the consensus is that we choose (a), can I ask that we don't use the term "idempotent" when documenting the restriction? I think it will cause too much confusion - we should explain the restriction without using obscure terms (and if it's hard to explain the restriction like that, maybe that demonstrates that it's an unreasonable restriction to impose? ;-))

Paul

More information about the Python-Dev mailing list