Literal.toPython() support for xsd:hexBinary

[bcogrel]

Following the discussion #386, here is an implementation of the bytes option, where toPython() returns a bytes value.

[bcogrel]

Now passing all the tests except one due to the nose last release nose-devs/nose#780 . This regression seems to be independent of this pull request and should affect the master branch as well. I was able to reproduce it and to prevent it by downgrading nose to 1.3.0.

[joernhees]

could you rebase this on top of master, should've fixed the problem with nose...

[joernhees]

why can't this just be (basestring, (hexlify, _XSD_HEXBINARY)),?

i guess i'll have to think about this a bit more...

[bcogrel]

My point was to distinguish a regular string from a hexstring with the xsd:hexBinary datatype.

In this implementation I put specific rules first, before generic rules. The distinction between specific and generic rules is based on the datatype. Please note that the ordering of these rules is important.

We could use the more compressed structure you propose (and change _castPythonToLiteral() accordingly) if we consider that no the function _castPythonToLiteral() should never return a default datatype for a regular string.

Indeed, the rule (basestring, (None, _XSD_STRING)) would not be generic anymore while in with my approach ((basestring, None), (None, _XSD_STRING)) is still generic.

I think it is better to keep the distinction between the incoming and outcoming datatypes.

[coveralls]

Coverage increased (+0.03%) when pulling 7ea1383 on bcogrel:hexstring-bytes into ad097cc on RDFLib:master.

[bcogrel]

I rebased it and now all tests passed. Thanks

[gromgull]

This looks more or less ok to me - probably there will be other cases where it may be useful to have a special lexical form constructed based on a datatype. For example, you could write a rule for casting a datetime to just a date - slightly contrived example:

from datetime import datetime
now = datetime.now()
l = Literal(now, datatype=XSD.date) 

Anyone else? Any reason not to make the literal-mapping rules more powerful?

You'll have to update the bind method as well though: https://github.com/RDFLib/rdflib/blob/master/rdflib/term.py#L1493

and this: https://github.com/RDFLib/rdflib/blob/master/examples/custom_datatype.py

[bcogrel]

Because of the bind() function, I think it is better to separate generic and datatype-specific rules: these lists wouldn't have to be ordered anymore so adding new rules at runtime would be easier.

For backward compatibility, I propose to change the bind() prototype as follows:

def bind(datatype, pythontype, constructor=None, lexicalizer=None, datatype_specific=False)

[coveralls]

Coverage increased (+0.05%) when pulling 3e02afe on bcogrel:hexstring-bytes into ad097cc on RDFLib:master.

[bcogrel]

What should I change in the custom datatype example?
https://github.com/RDFLib/rdflib/blob/master/examples/custom_datatype.py

To me, it is fine, it just shows a simple usage.

[nicholascar]

This PR has been re-issued in PR #979 to cater for Python 2/3 differences and since the original repo has gone away.