On Jul 8, 2:25 pm, Terry Reedy <[EMAIL PROTECTED]> 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.
--
http://mail.python.org/mailman/listinfo/python-list
