[Python-ideas] PEP 426, YAML in the stdlib and implementation discovery

[Brett Cannon]

On Fri, May 31, 2013 at 2:57 PM, Philipp A. <flying-sheep at web.de> wrote:
> 2013/5/31 Brett Cannon <brett at python.org>
>>
>> So yaml is not going to end up in the stdlib. The format is not used
>> widely enough to warrant being added nor have to maintain a parser for
>> such a complicated format.
>
>
> [citation needed]

OK, I claim it isn't as widely used as I think would warrant
inclusion, you disagree. Asking for a citation could be thrown in
either direction and on any point in this discussion and it comes off
as aggressive.

>
> it’s omnipresent in the ruby community *because* it’s nicer than JSON and
> XML, and *because* the ruby stdlib has a parser (my interpretation, of
> course, but not a unlikely one, imho).

That's fine, but that's not a reason to add it to Python's stdlib.
Adding anything to the stdlib takes careful thought because the burden
of maintenance is high for any code that lands there. From my POV a
YAML module just isn't there.

> and again, to intercept the “unsafe”
> argument: naming the unsafe load function “load” creates human error. naming
> the safe one “load” prevents it. i’m sure of that, too: nobody may honestly
> say he didn’t know that “unsafe_load” is unsafe.
>
>> > (Although that’s probably easily done by just not doing “import yaml”,
>> > but
>> > “import std_yaml” or “import pyyaml2”)
>>
>> The standard practice to to place any accelerated code in something
>> like _yaml and then in yaml.py do a ``from _yaml import *``.
>
>
> that’s what i said. just that _name implies internal, implementation
> -specific, rapidly changing code, which doesn’t fit my vision of a strict
> API that “_yaml” and compatible implementations should implement. but maybe
> an infobox in the stdlib yaml documentation telling the user about it is
> sufficient.
>
>> But that then creates a possible position where just to read metadata
>> you must have a 3rd-party library installed, and I view that as
>> non-starter.
>
>
> that’s exactly why i presented those 3 ideas as one: they work together best
> (although the implementation discovery isn’t mandatory)
>
>> It's simpler, it's Python syntax, it's faster to parse.
>
>
> wrong, wrong and irrelevant.

It might be irrelevant to you, but it isn't irrelevant to everyone.
Remember, this is for the stdlib which means its use needs to beyond
just what packaging wants.

>
> it’s only “simpler” for certail definitions of “simple”. those definitions
> target compilers, not humans. python targets humans, not compilers. (that’s
> e.g. why it favors readability over speed)
> also JSON is NOT python syntax, not even a subset: it has true, false and
> null instead of True, False and None,

For the purposes of what is being discussed here it is close enough
(the PEP mentions the use of none once).

> and also there’s a little hack
> involving escaped newlines which breaks code based on this assumption in
> awesome ways ;)
>
>> But making YAML a first-class citizen in all of this won't happen
>> as long as YAML is not in the stdlib and that is not a viable option.
>
>
> says you.

 Yes, says me. It's my opinion and I am allowed to express it here.

You are beginning to take this personally and become a bit hostile.
Please take a moment to step back and realize this is just a
discussion and just because I disagree with it doesn't mean I think
that's bad or I think negatively of you, I just disagree with you.