> Why did the list implementation get changed in Py3.x?

Because we decided to get rid of the sq_slice and sq_ass_slice slots
in PySequenceMethods, and that in turn was because we got rid of the
slice-related opcodes and the separate __getslice__ and __setslice__
magic methods.

> Is it now necessary for any subscripting type to put the same method
> in both the sequence methods and mapping methods?

Yes, if the type wants to support slicing.  The reason is that while
we changed many things, we didn't want to change the signature of the
methods that we kept, and the sq_item/sq_ass_item signatures have
arguments that make it impossible to pass the info necessary for a
slice.

> Was this change necessary?

The changes are briefly mentioned in PEP 3100 without any motivation.
However I think the rationale was the observation that the old
sq_slice / sq_ass_slice took only integers (really ssize_t), meaning
that it was impossible to implement a sequence type taking a slice
with arguments outside the range supported by ssize_t (e.g. a custom
range type supporting huge longs).  Or with non-integral arguments.
This problem never existed for non-slice __get__ since one could
always implement mp_subscript / mp_ass_subscript.

Was it necessary?  I'm not sure	-- but that's water under the bridge. 	

Was it a good change?  From the	POV of Python code, yes.  The old
approach caused some	odd problems for classes implementing
__getslice__ / __setslice__ (since those were invoked after the
arguments had been pushed through the sq_slice / sq_ass_slice API).

> Personally, I think PyMapping_Check and PySequence_Check should be
> deprecated and removed. Like their Python counterparts,
> operator.isMappingType() and operation.isSequenceType(), they are
> unreliable at best in the face of not LBYL and abcs.

Right, calling PyMapping_Check() was never particularly reliable, and
extension modules depending on it probably always had subtle bugs. 

Perhaps it would be nice if we provided a C API to at least some of
the ABC package.