Skip to content

Conversation

@aldpuzz
Copy link

@aldpuzz aldpuzz commented Sep 11, 2025

#379: Issue with explicit_end set to False having no impact on small dump

Warning: this change is not tested yet

Any input is welcome ;)

…alse having no impact on small dump)

    yaml#379: Issue with explicit_end set to False having no impact on small dump
@perlpunk
Copy link
Member

It has been explained in #379 that the current behaviour is necessary because of the YAML 1.1 spec.

@aldpuzz
Copy link
Author

aldpuzz commented Sep 11, 2025

It has been explained in #379 that the current behaviour is necessary because of the YAML 1.1 spec.

I can't see it is necessary because of the spec. I only see it's necessary for concatenating. Even the example in the post doesn't have the end marks for the second value - why?

%YAML 1.1
--- foo
...
%YAML 1.1
--- bar

I just want to be able to produce a single-document output which is shown to the user. and they consistently ask me what these dots are for

image

@perlpunk
Copy link
Member

Even the example in the post doesn't have the end marks for the second value - why?

because the important part in this example was the part after the first document and before the second document.

@aldpuzz
Copy link
Author

aldpuzz commented Sep 16, 2025

What I read from the spec:

To support this scenario, a YAML document may be terminated by an explicit end line denoted by “...”, followed by optional comments. To ease the task of concatenating YAML streams, the end marker may be repeated.

https://yaml.org/spec/1.1/

No word about "must", "required", etc. pyyaml calls itself a "full-featured" framework, so where comes this resistance from against an optional feature?

Or differently asked: there is the explicit_end argument for some methods. What's its purpose? Why don't you just remove it?

@perlpunk
Copy link
Member

I think the open_ended attribute would have to be changed from what it is doing right now in PyYAML.

So, in YAML 1.2, the ... is always needed between two documents if the following document starts with a directive, unlike in YAML 1.1.

In my own YAML 1.2 emitter, I have two cases when I emit ....
If the document ends with a block scalar that has an indicator for trailing line breaks that need to be kept, I emit ... directly at the document end. (That's also the case for PyYAML, and your current PR would remove that behaviour. I think for such block scalars there should always be a ..., even after the last document)

I also have an open_ended attribute. I set it to true simply if a document is not explicitly ended with ....
And when the next document starts, and open_ended is set and the document starts with a directive, I emit ....

I think it would be possible to change PyYAML to that behaviour and still be compatible with YAML 1.1 (it would emit ... in cases where it is not strictly necessary, but that's ok IMHO, and pretty rare anyway).

@aldpuzz
Copy link
Author

aldpuzz commented Sep 16, 2025

I don't know if this is rare. I came across this because I'm using https://github.com/null-none/django-yaml-field. It's just one out of hundreds use cases where pyyaml could be helpful - some of them need these markers, others of them obviously don't need them. that's why developers implement configurations and arguments. personally, I prefer this flexibility over duplicating code (forking or re-implementing)

@perlpunk
Copy link
Member

I don't know if this is rare.

The cases I meant are really rare.

key1: |+
  some literal
  block scalar with trailing
  line breaks that should
  be preserved

...

In this case the string has 3 linebreaks at the end. The ... are not strictly required, but I consider them a good practice when such a string is at the end of a document. Same for >+ block scalars.
And there would be ... between multiple documents, when they use a directive.
Everywhere else it wouldn't have ... unless explicitly requested.

I would make a PR if there are chances of this getting merged, but I don't know if the maintainers have resources for making a new release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants