David Bremner <[email protected]> writes: > Michael J Gruber <[email protected]> writes: > >> during my first tests for Python 3.13 (hooray...) I noticed that some tests >> in T610 started to fail independent of that. It seems that with notmuch >> 0.38.1 on current Fedora rawhide, `notmuch_message_get_properties()` >> returns properties in a different order, while the tests expect a specific >> order. So I'm wondering: >> - Is there a particular order which the interface promises to deliver? >> - If yes: What could cause it to be different? >> If not there's some work to do making the tests independent of the order ... >> This is not glib again, is it? > > The order is the result of sorting the keys (property names) using the > system qsort. So the first is potentially explicable, but the second > suggests a strange (to me) collation order. Do you happen to know the > locale used by these runs? > > Ultimately the comparisons are done with strcmp (string-map.c).
OK, I misread the output (there seems to be some confusing line wrapping). The test with #= is not actually a key, just a line marker. The underlying problem seems to be the same: qsort behaving differently, or perhaps (but less likely, I think) different input to qsort from Xapian. We could force the output to be stable by sorting on lexicographic order (include the property value in the comparison). _______________________________________________ notmuch mailing list -- [email protected] To unsubscribe send an email to [email protected]
