Auto-box python-object as literals when passes as objects of triples to graph.add

[gromgull]

So that we can do:

>>> graph.add( ( URIRef("urn:person"), FOAF.name, "bob" ) ) 

and have a literal added automatically.

Previously we've been lax about allowing strings/unicode (or any object) to be added to stores (#200), so this may break backwards compatibility for people who may rely on our weird behaviour.

[gromgull]

In theory we could also auto-box subjects/predicates as URIRefs... but it may be confusing, if you do:

>>> graph.add(( "urn:bob", FOAF.name, "robert" ))

then you get a triple urn:bob foaf:name "robert" as you expect, but if you then go on to do:

>>> graph.add( ( "urn:bob", FOAF.knows, "urn:bill" )) 

you get urn:bob foaf:knows "urn:bill" ...

which is not what you want.

We could autobox, but with a warning?

[dzinxed]

It's already quite easy to make a mistake when manipulating the graph (I have to dump the whole graph often just to check why something isn't working), and this would probably add to the confusion. Maybe just throw a ValueError instead? If it's breaking someone's code, then maybe add a flag to Graph's constructor (e.g. safe=False) and check only if safe is True?

[gromgull]

checking for correct values was issue #200, just solved, this issue was for discussing the possibility of handling it "cleverly" - i.e. not just rejecting strings or numbers.

It may well be TOO clever though.

[ghost]

Is this pertinent still? RDFLib terms are now mandatory for all components of a triple, so that would rather seem to obviate an auto-boxing approach.

Or am I missing something?

[joernhees]

Yupp, in the current version adding non rdflib terms causes an AssertionError to be thrown.
As the second example of @gromgull shows, everything else quickly gets confusing. I guess this can be closed, reopen if necessary.