[ZODB-Dev] BTree ranges

[Tim Peters]

[John Belmonte]
> I use BTrees indexed by floats.  It's for a job scheduler, where keys
> are floating point seconds since the epoch.  (Actually, to deal with
> two jobs scheduled for the same instant, they keys are a (time, id)
> tuple.)

That's OK by me; I expect strings are more common, and the exclude_{min,max}
options in ZODB4 were added specifically to ease a problem with path-keyed
mappings Steve Alexander was facing.

>> Your point is well taken but futile as given:  it would break far
>> too much code to change this.
>>
>> However, in ZODB4 the relevant BTree methods have grown optional
>> exclude_min and exclude_max Boolean arguments.  There, e.g.,
>>
>>     tree.items(10.0, 20.0, exclude_max=True)
>>
>> does what you want.  Since that's a new feature, it can't be added
>> to the 3.1 or even 3.2 versions of ZODB.  It may get backported to
>> a 3.3 version of ZODB (if such a thing ever exists).

> That's fine for the moment, and it reduces the complexity of wrapping
> the interfaces to do the right thing, but I would like to see a long
> term plan to fix this design misstep.  For example, make everyone
> aware that in ZODB 5.0 exclude_max will default to false,

You mean True here, right?  It defaults to False now.

> and in ZODB 6.0 exclude_max will be removed.  At least our great-
> grandchildren can have a sane interface.

I like having the choice -- half-open isn't convenient for all applications
either.  If you need to find everything keyed from 10.0 thorough 20.0
inclusive, being forced to use a half-open range search is just as clumsy as
trying to find everything keyed from 10.0 up to but not including 20.0 while
being forced to use a closed ranged search.  There is a smallest
representable float strictly larger than 20.0, but there's also a largest
representable float strictly less than 20.0 -- computing either is a PITA.
So I expect the options will stay, on pragmatic grounds.  Then changing the
defaults will be hard to sell, as there's no way to generate a sensible
warning message before the transition (short of warning about all calls that
accept the default).