-
Notifications
You must be signed in to change notification settings - Fork 517
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
The yaml.load{,_all} functions require Loader= now
- Loading branch information
1 parent
2f87ac4
commit c274365
Showing
2 changed files
with
5 additions
and
43 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
c274365
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ingydotnet making an argument required on this interface feels like a pretty pointless thing to do, what's the rationale here? This obviously breaks a lot of things for no apparent reason (not that dependencies can't be pinned, but interface changes for parsing/emitting library for a stable serialization format is a bit questionable...).
c274365
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was a decision we came to as a team. Leaving it using an exploitable loader was looking to be an endless source of CVEs from "well-meaning" individuals, and changing it to a different loader poses a number of problems for the future of the library. e.g., did you want a pure-Python loader, a libyaml loader, a libfyaml loader, a 1.2 or 1.3 loader? Once that's decided, which tagset should it use? Then what happens when we add new functionality to the library- do we enable that on the default loader and risk more ire from the breakage it causes? It's been issuing pretty obnoxious deprecation warnings for the past ~3 years on every 5.x release, so it definitely should not have been a surprise, and we waited for a major release boundary to make the change. Just be explicit about what your code needs, and life will be good. 😄
c274365
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The spec is on 1.2, don't see anything in the spec about 1.3. The "safe" C-based encoder and decoder is the clear candidate as the 99% use-case for the entire ecosystem I would think. Would rejoice at that kind of change rather than leaving it up to the caller (defeats all safety and correctness arguments against...).
Should there be new functionality that's not additive, if the implementation-to-spec isn't feature complete? Topmost interface churn is not generally a good indicator of health in a package...
Definitely appreciate clean ups!
c274365
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PyYAML as it stands today is mostly-1.1-with-some-1.2-stuff, and we're working on getting full-fledged 1.2 support in soon; there's also talk of creating new parallel classes as a testbed for 1.3 support. If we made that change today,
yaml.load()
would probably use a 1.1SafeLoader
(or aFast
variant we've toyed with for best-effort-use-libyaml-if-we-can); when we add full 1.2 support, I'm sure folks writing new code would expect thatyaml.load()
would use that by default, but that'd be another breaking change, because people again weren't being specific about what they're loading and the level of functionality they expect from the deserializer. If we solve that problem once with a breaking change now (by forcing people to be explicit about what they want), we shouldn't ever need to solve it again, no matter how many new options we add in the future.c274365
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood, thanks for responses and insight @nitzmahone. Will plan on following along with the upcoming efforts!
c274365
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Documentation at https://pyyaml.org/wiki/PyYAMLDocumentation needs to be updated.