I just have one thing to add to the discussion, which is this:
https://youtu.be/hAnCiTpxXPg?t=6339
Yes, people actually read and interpret our documentation :) So
discussions like this are probably a good thing in terms of getting the
best descriptions in there, but if we use a specific
> On Mar 8, 2019, at 12:12 AM, Steven D'Aprano wrote:
>
>> On Fri, Mar 08, 2019 at 12:56:13PM +1300, Greg Ewing wrote:
>>
>> In any case, the word is easy enough to avoid in this case.
>
> I don't think we should avoid using standard terminology even if we can.
> Knowledge of standard
On Fri, 8 Mar 2019 at 02:54, Inada Naoki wrote:
>
> Personally speaking, I think technical jargon is much easier than
> normal English idioms or complex English syntax.
>
> I learned "idempotent" long ago while learning HTTP. On the other hand,
> I don't know normal English idioms even 5-year
On Thu, 7 Mar 2019 at 23:58, Greg Ewing wrote:
>
> Paul Moore wrote:
> > There's a subtle difference in the mathematical
> > and computing meanings [of idempotent] (around functions
> > with side-effects, which aren't a thing in maths)
>
> Not really an issue here, since optionxform shouldn't be
>
> > We could say something like:
> >
> >"The optionxform function transforms option names to a
> >canonical form. If the name is already in canonical form,
> >it should be returned unchanged."
>
> How about:
>
> "The optionxform function transforms option names to a
>
On Fri, Mar 08, 2019 at 12:56:13PM +1300, Greg Ewing wrote:
> In any case, the word is easy enough to avoid in this case.
I don't think we should avoid using standard terminology even if we can.
Knowledge of standard terminology is useful, and we don't generally make
a practice of talking
Paul Moore wrote:
There's a subtle difference in the mathematical
and computing meanings [of idempotent] (around functions
> with side-effects, which aren't a thing in maths)
Not really an issue here, since optionxform shouldn't be having
side effects if it's sane.
In any case, the word is
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
07.03.19 11:18, Inada Naoki пише:
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
On Thu, 7 Mar 2019 at 12:42, Steven D'Aprano 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
On Thu, Mar 07, 2019 at 09:56:49AM +, Paul Moore wrote:
> On Thu, 7 Mar 2019 at 09:21, Inada Naoki wrote:
> > The document of the optionxform shows example
> > overrides it to identity function `lambda option: option`.
> >
>
> 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")
On Thu, 7 Mar 2019 at 10:06, Inada Naoki wrote:
>
> On Thu, Mar 7, 2019 at 6:57 PM Paul Moore 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
On Thu, Mar 7, 2019 at 2:51 PM Inada Naoki wrote:
> Hi, all.
>
> I came from https://bugs.python.org/issue35838
> Since there are no "expert" for configparser in
> Expert Index, I ask here to make design decision.
>
There is lukasz.langa in the expert index for configparser at
On Thu, Mar 7, 2019 at 6:57 PM Paul Moore 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
On Thu, 7 Mar 2019 at 09:21, Inada Naoki 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
Hi, all.
I came from https://bugs.python.org/issue35838
Since there are no "expert" for configparser in
Expert Index, I ask here to make design decision.
The default behavior of CofigParser.optionxform
is str.lowercase(). This is used to canonicalize
option key names.
The document of the
17 matches
Mail list logo
