- The next degree of sophistication above containment is the sized protocol, which allows us to determine
- how many items are in a collection by passing it to the len built-in function, which always returns a non-
- negative integer.
- Let's put some test together for that. First we define our new test case TestSizedProtocol.
- Going on the old adage that there are only three interesting numbers in computing science, 0, 1, and N,
- we test those three cases first using 10 in place of N. (Typing)
- Our fourth tests ensures that duplicate items passed to the constructor are only counted once, important
- behavior for a set. On running the test you'll get four failures of the form object of type SortedSet has
- no len(). To get the test passing, we need to implement the special dunder-len method to which the built-in
- len() method delegates. Again, we in turn delegate by calling len() on the underlying list.
- This improves matters, but our fourth sized protocol test is still failing with an AssertionError that
- three does not equal one. This test covers a combination of initializer behavior and conformance to the
- sized protocol, but the most important thing is that we have this test somewhere in our test suite.
- To fix this failure, we need to eliminate duplicate items in the series passed to the constructor.
- The easiest way to do this is to use them to construct a regular set, the built-in set type, which we can then
- use in turn to construct the sorted list. This approach has the added advantage that the set constructor
- is a good model for what we would like our constructor to support, so by delegating to it directly we can
- be sure that the SortedSet constructor is compatible with the set constructor.
- With this change in place, all of our tests are passing again.
- The sequence protocol implies the iterable protocol, so we'll have to implement that before we move on
- to sequence.