[ZODB-Dev] BTree ranges

[Tim Peters]

[Tim]
>> I like having the choice -- half-open isn't convenient for all
>> applications either.

[John Belmonte]
> Would you give a real-world example, from an existing application, of
> half-open not being convenient?
>
> The point of pulling some range out from a set is to slice the set.
> Slices shouldn't overlap.  If some program is using overlapping
> slices, the programmer was probably not conscious of this overlap,
> and it may well be a bug in the program.

Range searches are often used to develop query results.  In any inverse
index keyed on a finite discrete coded set (e.g., 1="hated it" thru
10="loved it"), there's no natural value "after the largest one".  If you
want to find everyone who "didn't hate it", inventing an artificial key of
11 just so you can get at 2 thru 10 via index.values(2, 11) seems contorted
to me.  Current practice is to do index.values(2, 10), which doesn't seem to
confuse anyone in practice (note that the BTree range search syntax doesn't
use an infix colon, like Python's half-open slice notation uses -- they
don't look the same, and they don't act the same; note too that it would be
possible to add support for infix colon notation, in which case half-open
semantics would be compelling for syntactic reasons alone).

It's worse if you have an inverse index keyed, e.g., by a year's days,
because "December 32" may not even be spellable.  The same usually applies
to any user-defined class whose instances model a fixed set of ordered
values -- making up a dummy value "beyond the end" just isn't useful now
(although defining a class.MAX constant often is).  If searches were
constrained to half-open, inventing a dummy value beyond the end would
become essential.