'<char> in <string>' works, why doesnt '<string> in <string>'?

[Magnus Lie Hetland]

In article <4abd9ce7.0203102128.67c7fa0d at posting.google.com>, damien
morton wrote:
[...]
> The existing mass of python code would be unchanged.

What evidence do you base this on?

> The only issue that might occur is that something that is now an
> error, would not be.

Assuming that this statement were true, how does it follow that 'the
existing mass of python code would be unchanged'? As I am sure you are
well aware, exception handling is an important part of the control
flow in any Python program. If something that previously raised an
exception no longer does, any program relying on that behaviour would
be broken.

Just to take a quick example -- checking whether a given string is a
lowercase character:

>>> from string import lowercase
>>> def islowercaseletter(object):
...     try: return string in letters
...     except: return 0
...
>>> islowercaseletter('x')
1
>>> islowercaseletter('X')
1
>>> islowercaseletter(2)
0
>>> islowercaseletter('foobar')
0

If your suggestion was accepted, the latter would suddenly return true.

And this is assuming that your statement is true -- which I really
think it isn't. It would not be a simple matter of making this check
illegal. You would have to sort out all kinds of things wrt. strings'
relationship to sequences and how strings are iterable. Since the
suggestion is full of inconsistencies, these would have to be patched
up somehow. For instance, assuming that you still want to be able to
iterate over the characters over a string (or, for that matter, still
want to be able to use indexing or slicing on them), you would
suddenly end up with the following oddity (among *many* others):

>>> 'foo' in 'foobar'
1
>>> 'f' in 'foobar'
1
>>> 'foo' in iter('foobar')
0
>>> 'f' in iter('foobar')
1

Strings would then be the only (built-in or standard lib) iterable
with this behaviour.

> It remains to be seen whether or not the mass of python programmers
> are opposed.

I think this is as good as certain.

> No-one has taken me up on my question about what circumstances one
> would want "'fox' in 'the quick brown fox'" to throw an exception,
> rather than return a result.

Well, I've given you one example. But that is really besides the
point. The point (as I see it, anyway) is that your suggestion either
makes Python thoroughly inconsistent, or necessitates a very large
change in the language core, removing the parts of strings that are
polymorphically equivalent to sequences and other iterables. I think
we'd end up with some very puny strings.

What *is* strange is that the string method index() is not
polymorphically equivalent to the list method index(). If one were to
model the behaviour of the membership operator on that, one would end
up with your suggested behaviour:

>>> ['a', 'b', 'c'].index(['b', 'c'])
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: list.index(x): x not in list
>>> 'abc'.index('bc')
1

I must say I'm baffled by the fact that str.index accepts something
other than a single character as its argument, but that's the way it
is.

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org