Assert at runtime or assert at unit test time, it's assertions all the way down? Not sure the benefit of some weird @decortator-like syntax to achieve 5-10 lines of assertions?
This is the big mix up with DbC in general I think. Think of it more like sanity-tests and assertions that help ensure your program isn't in some haywire state.
A good example with the BTree is that the invariants ensure the properties are enforced at runtime, but you still need test to invoke those properties.
These sorts of invariants mix really well with property-style tests:
You write some declarative specification for a set of boundaries on inputs/outputs, and then subject your classes to the generated inputs. If your tests pass, then all your invariants have held and you know at the bare minimum, the data structures are doing what you intend them to do.
Above that you can do load-testing and subject the invariants to scale-factors.
Also different from assertions in that 'class' invariants applies to every public method of the class.
: All I know about 'Design by Contract' I learned it in the (very good IMHO) book Object Oriented Software Construction by Bertrand Meyer (he made the Eiffel language).