[Zope-dev] Re: Zope 2.8: ZODB fix breaks undoable_transactions

[Tim Peters]

[yuppie]
> ...
> Don't know what other people think. I believe restoring the old undoInfo
> behavior and adjusting the documentation would be the best solution.
> Fixing this in undoable_transactions would fork the behavior of both
> methods and fixing all products that depend on the old behavior would
> cause unnecessary trouble.

Can you document the behavior you want?  Because there were multiple
bugs in the implementation before, I'm not exactly sure what "old
behavior" was in all cases; I'm certain that _some_ of it was purely
accidental, never intended, and utterly surprising (when last < 0). 
ZODB/interfaces.py's IStorageUndoable.undoLog documents the current
behavior, which matches what ZODB's UML docs have always claimed
behavior should be.  This behavior is tested in ZODB too now, so any
change here requires fiddling code, docs and tests.  If Zope requires
particular behaviors, it should grow tests for those too.

I'd be happy enough changing `first` and `last` to act like Python
slice indices instead, with the caveat that because there's other
weird non-Python behavior mandated when last < 0 (then undo{Log,Info}
are documented as taking the absolute value of `last` as being an
upper bound on the # of results to return -- and "old behavior" was
related to that, albeit with bugs of its own), they cannot act like
Python slice indices unless `first` and `last` are both non-negative.