You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’ve been working on a project that extends YAML with some additional features by making heavy use of custom tags, and I’ve run into a couple of issues related to how colons are treated in YAML. Specifically, I’d like to propose two potential changes to the YAML spec that would make YAML more intuitive for tag-heavy use cases like my own:
1. Disallow colons at the end of tag names
In YAML, the colon (:) is almost always treated as the beginning of a mapping, except in literal strings, literal style blocks, or (strangely) at the end of tag names. In the YAML spec, colons can appear anywhere in tag names, so !foo: is a fine tag. However, this creates some unexpected behavior because in all other cases but the ones I mentioned, a colon followed by whitespace (: ) means a mapping. I will happily enumerate my favorite surprising cases, if that is helpful.
That being the case, this tag behavior is unintuitive to me, and in my project, it introduces significant complications. I have to preprocess my YAML input to insert a space inside tags like !foo: so that the tag's constructed object will be used as a mapping key.
Proposed Change:
Modify the YAML spec to disallow colons at the end of tag names (e.g., !foo:), thus making the behavior more consistent with how colons are treated elsewhere in the language. Colons inside the tag would still be fine, as is true elsewhere.
2. Allow tags to begin literal-style values
Currently, YAML tags don’t allow their associated values to start as literal style without the explicit | or > markers. This forces users (like me) who are working with complex tagged values to use the | block indicator even for small values if they want to avoid issues with quotes, apostrophes, or colons in the value itself.
For example, in my project, I want to be able to use a tag like !expr and have the associated value treated as a literal string without requiring the |. This would simplify my YAML files significantly and make them easier to read. Parenthesizing is often an option, but cannot overcome the might of the colon, as (['" is a perfectly acceptable plain-style YAML mapping key. (A case where it works well is ("YAML's strings").)
Proposed Change:
Allow tagged values to start as literal-style strings until the next newline, without requiring | or >. This would make it easier to work with complex values, especially when combined with custom tags.
Context
I’ve been using Ruamel for my project and checking its behavior against PyYAML, and this behavior appears consistently across both parsers, so I believe these issues are rooted in the YAML spec itself rather than just implementation quirks.
The first change would make YAML more consistent by aligning the behavior of colons in tag names with their behavior elsewhere, and the second change would reduce the verbosity required when working with tagged values, particularly in cases where users need a lot of short values with high symbol complexity (lots of quotes and colons).
I’m happy to provide further examples if needed or to contribute to any discussion around these proposals. Thank you for considering these suggestions!
The text was updated successfully, but these errors were encountered:
Hello YAML maintainers and community,
I’ve been working on a project that extends YAML with some additional features by making heavy use of custom tags, and I’ve run into a couple of issues related to how colons are treated in YAML. Specifically, I’d like to propose two potential changes to the YAML spec that would make YAML more intuitive for tag-heavy use cases like my own:
1. Disallow colons at the end of tag names
In YAML, the colon (
:
) is almost always treated as the beginning of a mapping, except in literal strings, literal style blocks, or (strangely) at the end of tag names. In the YAML spec, colons can appear anywhere in tag names, so!foo:
is a fine tag. However, this creates some unexpected behavior because in all other cases but the ones I mentioned, a colon followed by whitespace (:
) means a mapping. I will happily enumerate my favorite surprising cases, if that is helpful.That being the case, this tag behavior is unintuitive to me, and in my project, it introduces significant complications. I have to preprocess my YAML input to insert a space inside tags like
!foo:
so that the tag's constructed object will be used as a mapping key.Proposed Change:
!foo:
), thus making the behavior more consistent with how colons are treated elsewhere in the language. Colons inside the tag would still be fine, as is true elsewhere.2. Allow tags to begin literal-style values
Currently, YAML tags don’t allow their associated values to start as literal style without the explicit
|
or>
markers. This forces users (like me) who are working with complex tagged values to use the|
block indicator even for small values if they want to avoid issues with quotes, apostrophes, or colons in the value itself.For example, in my project, I want to be able to use a tag like
!expr
and have the associated value treated as a literal string without requiring the|
. This would simplify my YAML files significantly and make them easier to read. Parenthesizing is often an option, but cannot overcome the might of the colon, as(['"
is a perfectly acceptable plain-style YAML mapping key. (A case where it works well is("YAML's strings")
.)Proposed Change:
|
or>
. This would make it easier to work with complex values, especially when combined with custom tags.Context
I’ve been using Ruamel for my project and checking its behavior against PyYAML, and this behavior appears consistently across both parsers, so I believe these issues are rooted in the YAML spec itself rather than just implementation quirks.
The first change would make YAML more consistent by aligning the behavior of colons in tag names with their behavior elsewhere, and the second change would reduce the verbosity required when working with tagged values, particularly in cases where users need a lot of short values with high symbol complexity (lots of quotes and colons).
I’m happy to provide further examples if needed or to contribute to any discussion around these proposals. Thank you for considering these suggestions!
The text was updated successfully, but these errors were encountered: