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

Steven D'Aprano steve at pearwood.info
Thu Mar 7 07:39:50 EST 2019

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

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

More information about the Python-Dev mailing list