[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Inada Naoki wrote:

> a)  Document "optionxform must be idempotent".

> b) Ensure all APIs calls optionxform exactly once, and document
 >    [that it must be idempotent in certain special situations].

I think the question that needs to be asked is whether optionxform
is meant to be a canonicalising operation, or a transformation
from an external to an internal form.

Although the docs don't say so explicitly, it seems clear to me
that the author of the module was thinking of it as a transformation
to a canonical form. If that's what is intended, then idempotency
is pretty much implied, from the definition of what canonical
means. If something is already in canonical form, nothing needs
to be done.

The behaviour with regard to initialising from a dict that was
raised in https://bugs.python.org/issue35838#msg334439 is probably
an oversight, but there are at least two other ways that the
module assumes idempotency:

1) The API does not provide any way of accessing an option
*without* applying the transformation. This is a problem if e.g.
you want to iterate over the keys and write values back.

2) The write() method writes out the transformed versions of
option names. If this output is read back in, the transformation
will necessarily be applied a second time. There doesn't seem
to be any workaround for this.

There may also be other ways in which idempotency is assumed
that I haven't thought of.

So, rather than try to have the docs list all the things that
non-idempotency could break, it would be easier to simply
document that idempotency is assumed.