String xsd:double value crash toRrdf()

[anatoly-scherbakov]

Why

Here's a JSON-LD document.

{ "@context": { "xsd": "http://www.w3.org/2001/XMLSchema#", "geoLongitude": "http://www.w3.org/2003/01/geo/wgs84_pos#longitude" }, "@graph": [ { "@id": "http://www.wikidata.org/entity/Q399", "geoLongitude": { "@type": "xsd:double", "@value": "45" } } ] }

Conversion of this document to a RDF dataset works at JSON-LD playground, but it will crash pyld 2.0.4:

 def _object_to_rdf(self, item, issuer, triples, rdfDirection): """ Converts a JSON-LD value object to an RDF literal or a JSON-LD string or node object to an RDF resource. :param item: the JSON-LD value or node object. :param issuer: the IdentifierIssuer for issuing blank node identifiers. :param triples: the array of triples to append list entries to. :param rdfDirection: for creating datatyped literals. :param rdfDirection: for creating datatyped literals. :return: the RDF literal or RDF resource. """ object = {} if _is_value(item): object['type'] = 'literal' value = item['@value'] datatype = item.get('@type') # convert to XSD datatypes as appropriate if item.get('@type') == '@json': object['value'] = canonicalize(value).decode('UTF-8') object['datatype'] = RDF_JSON_LITERAL elif _is_bool(value): object['value'] = 'true' if value else 'false' object['datatype'] = datatype or XSD_BOOLEAN elif _is_double(value) or datatype == XSD_DOUBLE: # canonical double representation object['value'] = re.sub( r'(\d)0*E\+?0*(\d)', r'\1E\2', > ('%1.15E' % value)) E TypeError: must be real number, not str 

What

This PR

• Creates a unit test demonstrating the problem,
• Contains a fix to it.

[anatoly-scherbakov]

@BigBlueHat @davidlehn please let me know what you think. Thanks!

[davidlehn]

• The code style is different. Extra newlines and such. Would be better to match what is there.
• None of the other code has type annotations. (This code pre-dates that even existing.) I'm not sure if we want to add that in new code piece by piece or add it all at once later.
• Does the test suite not cover this? If not, it should, so all implementations test this case. That might remove the need for the test file.

[anatoly-scherbakov]

1. I agree about importance of maintaining a unified code style. However, both describing such as style and mimicking it, are rather difficult if done informally. An automatic formatter, such as black, is often considered a fit resolution to such issues (even though I dislike certain decisions black does, I have to agree its benefits are worthwhile). We might consider introducing it to the project and to CI.

2. This is a matter of taste; IMHO type annotations are de facto standard in industry programming in Python, and I tend to use them in every piece of code I write, not even questioning whether I should, I am afraid. A typechecker can be introduced into development workflow and in CI to validate type annotations.

3. The purpose of the test is to a) illustrate the existence of the issue and b) the ability of the proposed fix to remedy it. Writing a test was a part of my debugging process when I discovered the problem when parsing a document from Wikidata, and I included the test as a material proof.

An extra test should not bring about much harm. It can be deduplicated and, if necessary, merged into the test suite of the API specification later.