Issue #355 resolved
Inconsistency in parsing unicode and str types in fields.NUMERIC
The attached code demostrated the inconstistency. Appending the irc log of my conversation with Thomas as a reference.
< maker > unicode() and str() give different outputs / < maker > apparently datetime is safe against this test, but fields.NUMERIC not ( < maker > (but I have to write more tests to assert that) < ThomasWaldmann > hmm? if it is NUMERIC, how is (u)"maker" valid? < maker > ThomasWaldmann u'maker' is not valid, but 'maker' yes < ThomasWaldmann > but that's not numeric < maker > I would have expected to have the same result with unicode and strings < ThomasWaldmann > are you using py? < maker > nop < maker > .. bit < ThomasWaldmann > well, guess you have to dig into the code to find out why. but maybe try if it happens also with more practical usecases, not only when giving totally invalid input. < maker > ThomasWaldmann mine is a practical case < maker > I have a reduce(operator.or_, Term(field, query) for field in fields) < ThomasWaldmann > how can "maker" be a valid term for searching a NUMERIC field? < maker > that's a query term; if I just want to search through all possible fields, I shouldn't care about its type. Moreover, str() behaves differently, which imo makes it a bug either way < ThomasWaldmann > yes, if it is invalid, it should just never match