On Thu, Nov 15, 2012 at 3:17 AM, Benny Malengier
> concerning this patch, I noticed that in Date our comparison methods are
> not very consistent. The <= and >= uses your match functions, < and > the
> sortval of the date. Then we have == and is_equal, and I now had to add
> __neq__ which will use sortval.
> As you are the expert with date, fixing that inconsistency is best done by
> you if you think it necessary. If so, I would suggest the operators to all
> use match, and to introduce a fast compare as function, which uses sortval.
> Then it is a matter of converting those pieces that need it to the sortval
> Well, a complicated and possibly unstability causing change, but if it
> needs to be done, better now for unstable 4.0
I'm looking at date comparisons and wondering if there is ever a need for
the fast but inaccurate method?
Background: the original method for comparing dates was to use a single
number for comparison, Date.sortval. One can quickly sort dates by sorting
on this number. However, the sortval does not take into account other
modifiers, like "before" or "after". That means that a "after 1900" date
will often be sorted before a "before 1900" date.
On the other hand, there is a newer method of comparison which uses a more
complete comparison, called "match". Match is currently not
very optimized (for example, it always creates two additional Date objects,
and changes to Gregorian if necessary). However, it can be used to sort the
dates as best that we can. It takes into account values for "about",
"before", and "after" to give good ordering.
In attempting to clean up this code, I am wondering if we should ever sort
dates fast but wrong? The match code might be able to be better optimized
(perhaps caching some values/changing database). I could do some
benchmarking on using match to sort if that would be useful. I guess that
if match is not much slower, we should probably not ever use sortval for
Comments or questions? Anything else to consider?
> 2012/11/15 Benny Malengier <benny.malengier@...>
>> Be carefull the following days with trunk, as there can still be some
>> unstability. In rev 20658 I have converted:
>> 1/ no more cmp and __cmp__, so also not in sort and sorted
>> 2/ bsddb needs a bytestring key, so b'string', which is str of python 2.
>> Fortunately, b'string' works in python 2
>> 3/ gtk in python 3 needs just str (so unicode), not utf-8 anymore
>> Gramps starts to work with python3, at least editors, and some views.
>> Only test with real test data, as low bsddb corruption errors still
>> Most remaining things I think will be unicode <--> bytestring <--> utf-8
>> issues, but if those go into the database, it could be problematic!