Those methods are a remnant of blist's implementation which include all the MutableSequence methods. It's been helpful, as a drop-in replacement, to have those methods implemented and raising NotImplementedError with useful error messages and doc strings. Raising AttributeError will be much more cryptic for folks.

Otherwise, I don't see much benefit with this change except appeasing type checkers which seems kind of dubious to me. Did you see a specific case where a type checker would have caught your concern?

Those methods are a remnant of blist's implementation which include all the MutableSequence methods. It's been helpful, as a drop-in replacement, to have those methods implemented and raising NotImplementedError with useful error messages and doc strings. Raising AttributeError will be much more cryptic for folks.

I have implemented a custom __getattr__ so that the same message is raised, just using AttributeError rather than NotImplementedError. The primary change here is the error type raised - if it raises AttributeError, hasattr and getattr will properly understand that these methods are not implemented, and any isinstance checks that work based on the interface will work correctly.

Otherwise, I don't see much benefit with this change except appeasing type checkers which seems kind of dubious to me. Did you see a specific case where a type checker would have caught your concern?

I have recently been trying to upgrade SortedList on a large code base with a lot of type checking. This would make it much easier to find situations where someone is programming as if something is a list and expecting .extend or .append to work, but what was actually passed was a SortedList.

Same thing with regards to dispatch - people dispatching on MutableSequence expect the thing to actually be a MutableSequence. This is just a mutable Sequence, which is a different thing.