Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


XSDToPython maps integer to long #217

salmonito opened this Issue · 4 comments

4 participants


_XSD_NS[u'integer'] : long, same for int.
Not sure what the rationale was to do that. In my application for example I have integer attribute, I read it as #integer literal, get python value as long, and update to long ending up with two values in my RDF store integer and long.


Origin is back in the mists of time - 6 years ago, according to github


was a chimezie commit - just a typo?


The "problem" of xsd:int being cast to a python long was introduced in 1676f9e . The log msg indicates that there was a problem with equality tests otherwise... maybe eikeon remembers more details, even though it's 5 years ago.

IMO the original chimezie commit was a bit more correct for integer, long and int: f05bc81#L0R44 as it follows the specs more closely: .
The does not make any assumptions about how big the number is, just that it doesn't have decimals. and make assumptions about how big the numbers can be and hence int can be cast to a python int using the additional info that a python int is at least 32 bit --> max 2**31-1 == 2147483647 (

The original and current version both are inconsistent in various ways, when it comes to xsd:.+Integer .As mentioned above for example the xsd:nonPositiveInteger doesn't make any assumptions about the length of the number. Nevertheless, it currently is interpreted as int in python (which actually isn't too bad, see below):

As python actually deals with int overflows gracefully by using long instead, why not make all the mappings int?

In [1]: int("4242424")
Out[1]: 4242424

In [2]: int("42424242424242424242424242424242")
Out[2]: 42424242424242424242424242424242L

That way python would dynamically decide if the value is small enough to be held in an int or if it needs a long. Only problem would be people relying on int/long to serialize to the correct xsd datatypes (which IMO is a bad idea).

@salmonito :
Maybe as a workaround you can try to downcast the long to an int in python prior to saving it into the database?


++ IMO the original chimezie commit was a bit more correct for integer, long and int

Thanks for the clarification, obviously I'd lost some focus by that stage of my forensics trawl.


In the new literal reworking branch - I've fixed this: 4e6cd68

ints in python transparently promote to longs when the values get to large, and longs have no limit. I find it odd to try to shoe-horn either of them into any particular concrete bit-limited xsd datatype. After discussing with Jörn, both are now mapped to xsd:integer

@gromgull gromgull closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.