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

[Paul Moore]

On Thu, 7 Mar 2019 at 12:42, Steven D'Aprano <steve at pearwood.info> 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".
>
> That's what "idempotent" means :-)

Sigh. I'm not interested in an extended debate on fiddly details here.

I know that's what "idempotent" means. I said I "wasn't clear", and
the context clarified it for me (as would going and looking it up,
which I *also* did).There's a subtle difference in the mathematical
and computing meanings (around functions with side-effects, which
aren't a thing in maths), which IMO makes the term *very slightly*
ambiguous - but more to the point, it's uncommon jargon in many areas
(searching for "idempotent" in Google shows enough examples of people
asking what it means to bear this out, IMO - feel free to disagree).

> > 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*

Why use possibly-misunderstood jargon when a clear description will
do? Hmm, let me think. I guess it depends on which
carefully-worded-to-make-your-point description of the situation you
choose to use. *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.

I didn't say otherwise. I said "I think it will cause too much
confusion". I stand by that. I value clear, non-technical, terms over
jargon when it's possible to express an idea that way without
sacrificing clarity. I believe that in this case this is possible
(although as I've already said, I think it's better to avoid the whole
question and *not* impose the restriction at all).

I have no idea what proportion of readers of the configparser docs
will be familiar with REST (or with maths, or with any other
context).I doubt you do either, but if you do I'll defer to your
knowledge.

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

I love that, I may start using it deliberately :-)

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

Agreed, but we should also express ideas in a way that is as
accessible to the general reader as possible. Sometimes that means
using (and explaining) precise technical terms, other times it means
using simple language that gets the job done, without using
*unnecessary* jargon. It's a judgement call as to where the dividing
line lies. So I feel that "idempotent" is on one side of the line, and
you think it's on the other. We've expressed our opinions, let's leave
it at that - I don't want to get into an extended debate over "my
experience of what the average user thinks is wider than yours"...

Paul