PEP to add yaml to standard library?

[znd4]

I haven't been able to find any existing peps about this, or issues in this repo, so I thought I'd ask:

Would it be reasonable to move pyyaml into the standard library at some point?

Searching the python-ideas mailing list seems to indicate that there hasn't been a lot of discussion about this there in a while.

I know that the maintainers of requests have decided to not move into the standard library because they need to be able to nimbly release security patches. I can understand that there could be similar reasons to avoid moving a parser into the standard library, since pyyaml is tracking the changing yaml spec.

Have changes in the yaml spec slowed down enough that it would be reasonable to stick to the python stdlib release cadence? Are there breaking changes often enough that it could cause problems?

I don't know enough about the yaml spec + it's lifecycle to be able to contribute meaningfully to the technical discussion, although I'd be willing to try to figure out what "the implications of standard library inclusion" are.

Thanks, sorry if this is bothersome

[nitzmahone]

Can't speak for anyone else, but I don't see a significant benefit to inclusion in stdlib over the likely hassle of doing so, especially since we're now shipping libyaml-integrated wheels for common (and some less common) platforms. There's also work actively going on to support YAML 1.2 that will likely involve fairly major API changes for the first time in many years. With that will almost certainly come some breaking changes to lower-level APIs, and quite possibly even the highest-level APIs. That all gets a lot more complicated if we're trying to thread fixes around a stdlib-included version of the library.

So with all that, it's a big -1 from me anyway...

[the-moog]

I would argue that before it can be included either ruamel.yaml and pyyaml should merge or pyyaml should catch up on key features in ruamel that pyhaml is lacking. I would vote for simply including ruamel instead.

[brnt-toast]

In 2023, just now, I was just looking to see if YAML was in the standard library. Sadly it isn't. I looked on the python wiki and it was outdated, pointing to websites that have been 301 redirected.

It wasn't until I read ansible's source code did see that they were using pyyaml. Personally I am very much interested and would lend a hand to help contribute.

[matthiasgeihs]

I think YAML in some contexts is the new JSON. I'm happy that JSON is part of the standard lib. YAML should be too.

[robcxyz]

IMO ruamel being hosted on sourceforge for some reason makes it a no go and for that reason people created ruyaml. I personally think if there is any library to start off of, it probably should be that one if people were thinking of doing this. I feel like if ruamel was on github to begin with it clearly would have been the standard and this PEP would have been well on its way. My 2 cents.

[nitzmahone]

IMO ruamel being hosted on sourceforge for some reason makes it a no go

I doubt the upstream hosting location would be a significant deterrent.

I didn't follow it closely, but IIRC there was a fair bit of controversy around the TOML-in-stdlib PEP (680), and that was four tiny pure-Python files. IMO, if not for the need to standardize TOML parsing for pyproject.toml, TOML wouldn't have made it into stdlib either (note that what did get included is very minimal, slow, and read-only). The Python core team are busy folks- I'm guessing the prospect of lifting-and-shifting a creaky old fitfully-maintained codebase like PyYAML into stdlib (along with its effectively-required-for-acceptable-performance native parser linkage) would probably go over like a lead balloon. ruamel.yaml (which started as a PyYAML fork) suffers from a lot of the same problems, and while its features like format/comment preservation are awesome, they're in explicit opposition to the current YAML spec, which is probably not what's desired in stdlib "stable" APIs.

TL;DR: 2023 me's opinion on this hasn't changed. :laughing:

[jjasghar]

I was surprised to find tomllib and not yaml in the stdlib the other day. I have always thought there was a "larger" adoption of yaml in the wild. The ROI for usability would be there for the down stream user.

[sj-porter-knime]

Kubernetes uses yaml, most build pipeline tools use yaml, my grandmother might even use yaml by this point...

I'd love to see it in standard library and I agree with @jjasghar that it is a usability issue. Relying on the standard library as much as possible for basic scripting is ideal so that nobody has to create virtual environments or install packages just to run a script that saves some data to a .yaml file.

[vpmartin]

Native yaml support in the standard library would be great.

I'm developing apps for a closed environment with a strict no-external-lib policy, only Python stdlib. Had to write a rather long config file, and chose to use YAML for it because it's so much cleaner, only to find out that YAML support needs pyyaml.

Using JSON instead makes the line count go from 60 to 100, and the character count from 1200 to 2000, while making it more complex to read and write. Advocating for YAML support in the stdlib!