[Python-Dev] configparser: should optionxform be idempotent?

[Steven D'Aprano]

On Thu, Mar 07, 2019 at 09:56:49AM +0000, Paul Moore wrote:
> 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.read_dict().
> > 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".

That's what "idempotent" means :-)


[...]
> > 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 don't have a strong opinion, but I have a mild preference for taking 
responsibility for idempotency out of the user's hands if practical.


[...]
> 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.

Writing idempotent functions often is.

 
> If, however, the consensus is that we choose (a), can I ask that we
> *don't* use the term "idempotent" when documenting the restriction?

Why use one word when twenty-four will do? *wink*


> 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? ;-))

Please, idempotent is a standard term of art, especially for those 
working with RESTful interfaces.

http://restcookbook.com/HTTP%20Methods/idempotency/

It might be obscure to you, but then nearly every jargon term will be 
obscure to somebody. Nobody is born knowing what terms like

    multiprocessing
    threading
    metaclass
    decorator
    comprehension
    futures

etc mean. They're all "obscure jargon" terms to someone. The first time 
I came across "tuple", I had no idea what it meant (and in fact it took 
me many years to stop misspelling it "turple").

By all means include a definition of idempotent (perhaps a link to the 
glossary). But we shouldn't avoid useful, precise terminology because 
some people haven't come across it yet.



-- 
Steven