http://docs.python.org/3.3/glossary.html#term-sequence

__getitem__ and __len__ are required for sequence type.
(__iter__ is not required because types having __getitem__ are already iterator.)

.__contains__(), .index() and .count() is not required for sequence.

For example, following class should be sequence.

class Foo:
    def __getitem__(self, index):
        if not isinstance(index, int):
            raise TypeError
        if index >= 3:
            raise IndexError
        return index

    def __len__(self):
        return 3

In Python 3.3:

In [33]: issubclass(Foo, collections.abc.Sequence)
Out[33]: False

Careful, though: dict also provides these methods, but I would not consider it a Sequence.

I think PySequence_Check() has same problem.

OTOH, mapping definition says:

> A container object that supports arbitrary key lookups and implements the methods specified in the Mapping or MutableMapping abstract base classes.
- http://docs.python.org/3.3/glossary.html#term-mapping

So the mapping should implement all methods defined in collections.abc.Mapping.

If the sequence should implement all methods defined in collections.abc.Sequence, it's a documentation bug.

Is there a common view about what is the sequence?

Many algorithms that require a sequence only need __len__ and __getitem__. The term "sequence" is used to distinguish such containers from mere iterables that only provide "__iter__" (and may be consumed by iteration). The glossary entry covers this use of the term.

collections.abc.Sequence is a much richer interface, which defines many additional operations beyond those iteration, indexing and slicing. Types which implement that full API can be registered explicitly (or else an application can define it's own custom ABC for a subset of the Sequence API).

However, the glossary entry should link to http://docs.python.org/3.3/library/stdtypes#sequence-types-list-tuple-range to expand on the second meaning of the term.

PySequence_Check is an unreliable guide (albeit not quite as unreliable as PyMapping_Check) that checks a CPython implementation detail.

As Amaury notes, implicit ducktyping is not feasible for sequences or mappings, as the method names overlap - you have to add explicit semantic information to say which kind of container you're implementing.

Thanks, Nick.

I see that the "sequence" doesn't have strict definition.

Though, I think collections.abc module's document should describe
this manner. For example:

"But checking type with these abc may be too strict for most case.
For example, some user defined sequence class may not cover
:class:`Sequence` abc. Using :term:`EAFP` manner is preferred in Python."

No, that runs counter to the purpose of ABCs. If you have a type that is "good enough" for your purposes, then you can just register it.

So, I feel the 2nd meaning of "sequence" should be collections.abc.(Mutable)Sequence.

"sequence types in stdlib" have richer API then the ABC. (e.g. comparison, +, *, etc...)
They are "APIs that sequence may have" but not "APIs makes the type sequence."

And nice symmetry with mapping entry.

Here's a possible patch that mentions collections.abc.Sequence.  I left out MutableSequence, because I couldn't see how to mention it without making the definition longer and more complicated.  

(It could be objected that this is the *glossary*, and is supposed to provide brief descriptions of terms, not precisely detailed descriptions.  In that case, the patch could simply be rejected.)

New changeset 30d0816939a3 by Andrew Kuchling in branch '3.3':
#16728: Mention collections.abc.Sequence in 'sequence' glossary entry
http://hg.python.org/cpython/rev/30d0816939a3

Looks like this was left open for post-commit review, but since no one has objected (and it looks fine to me) I'm going to close it.