Changes to graph.serialize()

[ashleysommer]

This is part of our work to simplify and modernize the methods on rdflib.Graph to clean up the API surface of the Graph.

These are some long-overdue changes to serialize(). This is a slightly breaking change, so will be coming as part of RDFLib 6.0.0, but is done in such a way as to minimize breakage as much as possible.

These changes are:

1. Change default format from 'xml' to 'turtle'
2. If serialize() destination=None and encoding=None, output is a str, not bytes
3. Add a new convenience method to print the Graph contents (turtle by default)

• eg to print the Graph as trig format: g.print(format="trig")

Lots of fixes in tests to adapt to these changes (serialize is used a lot to check graph state in tests).
Blacked files which were involved in this change.

[ashleysommer]

Note after these changes you can still get bytes output from serialize() if you pass it an encoding.

Eg:
g.serialize(format="xml") will give you str but
g.serialize(format="xml", encoding="utf-8") will give you bytes encoded as 'utf-8' and
g.serialize(format="xml", encoding="latin-1") will give you bytes encoded as 'latin-1' as expected

[nicholascar]

Just made a small edit to allow doctests to pass, awaiting Travis result

[coveralls]

Coverage increased (+0.08%) to 75.505% when pulling dd1a7b1 on serialize1 into 7a53c61 on master.

[white-gecko]

I understand the idea and I like that it is made easier now that a user does not need to ncessarily deal with the encoding, but having utf-8 per default. On the other hand I think it might confuse some users if adding the encoding parameter does not bring a string anymore but byte instead. This leads me to the more general question, why do we use ByteIO for the streams, why not StringIO instead?

[nicholascar]

it might confuse some users if adding the encoding parameter does not bring a string anymore but byte instead

Yes it might the first time, but this will be one of the changelog notes for 6.0.0, so they will be notified and hopefully only see the issue the first time.

why do we use ByteIO for the streams, why not StringIO instead?

Perhaps just due to a lack of consistent development? Would you like to convert across to StringIO everywhere? @ashleysommer, is that sensible? Sounds fine to me to have string as default unless it's slow for large datasets. Can always be converted back