On Thu, 7 Mar 2019 at 12:42, Steven D'Aprano <st...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
