Closed eharpste closed 8 years ago
This bug actually extends to any use of a non-string, non-tuple as a key. I vote we enforce that only strings and tuples are allowed to be key values.
I've been looking into how to possibly fix this one and I was hoping it could be put on the tail end of a pre-processor but that won't work for cobweb and cobweb3. So now I'm contemplating either running a process over any instance at the first call to cobweb that stringify's the keys (and possibly clobbers duplicates), or putting type checks throughout the code to avoid the indexing error. I suppose I could make a branch and check relative performance.
If a relation containing a raw numeric value, i.e.
('foo', 12.5, 'o2')
instead of('foo', '12.5', 'o2')
, the structuremapper will throw an exception because indexing into a Number isn't valid when the mapper is looking for a first character `''or
'?'`.We could handle this by casting all relation element to strings or by having logic throughout the structure_mapper to handle Numbers in some special way. On one hand Numbers are valid dictionary keys in python and so we should (maybe?) support them but on the other we mostly assume that we are categorizing JSON objects which mandate keys be strings.