On Thu, 7 Mar 2019 at 09:21, Inada Naoki <songofaca...@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".
> 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
_______________________________________________
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
