"in"consistency?

[castironpi]

On Jul 8, 2:25 pm, Terry Reedy <tjre... at udel.edu> wrote:
> castironpi wrote:
> > Strings are not containers.
>
> Library Reference/Built-in Types/Sequence Types says
> "Strings contain Unicode characters."
> Perhaps you have a different notion of contain/container.
>
> I prefer 'collection' to 'container' since 'container' tends to imply an
> exclusiveness that is not true.  Byte/character sequences *are*
> different from tuples, lists, sets, dicts, etc, in the following sense:
> members of the latter collection classes must exist first before being
> added to the collection (non-exclusively).  Members of the former do
> not.  (In CPython, at least, they do not).  So I consider them to
> (reiterable) *virtual* sequence collections that can produce
> subsequences on demand,
>
> So I partially agree with you in that byte/char sequences are a
> different sub-category.
>
> > Another container type:
>
> > Python 3.0b1 on win32
> >>>> {0} in {0,1}
> > False
>
> And similarly, (0,) not in (0,1), [0] not in [0,1], {0:None} not in
> {0:None,1:None).  These are all general manifest collection types that
> can contain any Python object, and which could contain a sub-collection
> even if they do not.
>
> Terry Jan Reedy

Under that definition, "a" in "abc" is clearly well-defined.  I
construe "abc" to "contain Unicode characters", specifically, "a",
"b", and "c".  But "ab" is not a Unicode character.

"Contain" is still a good word for what strings "do", to the extent
that they "do" anything at all.  The fact that they contain a uniform
data-type permits the extension of "in" to subset/substring testing.

Compare to an imaginary "set of ints" data type:

>>> a= setofints( [ 0, 1, 2 ] )

Then, the semantics of

>>> b= setofints( [ 0, 1 ] )
>>> b in a
True

are consistent and predictable.  Correct me if I'm wrong.