Thanks, I don't think it matters much but I would prefer the svg examples to use io.StringIO since svg is fundamentally a text format.

On the other hand, it buffer is being used to stand in for an open file handle which should be bytes?

The file is opened in w mode i.e. write text mode in print_svg If I understand https://docs.python.org/3/library/io.html#text-i-o and https://docs.python.org/3/library/io.html#binary-i-o correctly then io.StringIO is what replicates this behaviour and is.BytesIO replicates wb and rw mode

The SVG backend will wrap any file-like objects opened in binary mode with a UTF-8 text encoder, so it's not actually necessary to pick one over the other based on the strict difference between io.BytesIO and io.StringIO, .

The SVG backend will wrap any file-like objects opened in binary mode with a UTF-8 text encoder, so it's not actually necessary to pick one over the other based on the strict difference between io.BytesIO and io.StringIO.

Just wanted to add a "ditto" here. One of the reasons it's designed this way is so that users can pass the same bytes-writing file object to any of the backends and have it work (since many of the output formats are binary). The inverse wouldn't be true, i.e. one couldn't write PNG to a text-writing file object.

Yes it's all bikeshedding and the only question is if one thing is more clear than another in the SVG examples?

I have changed them over to io.StringIO in a local commit and will merge locally, push and backport.

Also, those interactive demos are super cool!

Merged to master via cf38ed7

backported as 9fe5abe