>
> That argument could be used for any use of optionxform, though -
> instead of using the default optionxform, use explicitly-lowercased
> values everywhere instead.
>
It can't be usable if the config format case-insensitive.
value = (cfg.get("section", "name") or cfg.get("section", "Name")
or cfg.get("section", "nAme") or cfg.get("section", "naMe")...)
> I still prefer option (b), allowing general functions for optionxform.
> However, I will say (and I should have said in my first mail) that
> this is a view based purely on theoretical considerations. I've never
> explicitly used optionxform myself, and none of my code would be
> impacted in any way regardless of the outcome of this discussion.
>
> Paul
If we choose (b), I think core developer must check test coverage for
optionxform before documenting non-idempotent optionxform
is allowed explicitly.
I don't have motivation for that because I never used configparser in such way.
The PR looks good to me for the particular case the issue describe.
So I will merge the PR without updating document when we chose (b).
But let's wait a few days for other comments.
Regards,
--
Inada Naoki <songofaca...@gmail.com>
_______________________________________________
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
